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ABSTRACT 


In  an  era  of  diminishing  budgets,  information  technology 
must  help  direct  operational  commanders  in  the  maximum 
utilization  of  their  available  resources.  The  institution  of 
a  relational  database  management  system  to  identify  and 
exploit  an  organization's  strengths  will  aid  in  keeping  forces 
combat  ready  at  all  times.  The  design  and  implementation  of 
ZTRAX;  a  training,  readiness  and  flight  hour  relational 
database  management  system.  ZTRAX  is  expected  to  provide 
historical  information  of  home  and  deployed,  operational  and 
training  flight  evolutions  which  will  aid  in  the  process  of 
training  and  readiness  planning.  The  ZTRAX  application  was 
implemented  in  November,  1991  and  is  a  menu  driven  program 
which  permits  the  addition,  editing  and  querying  of  data 
contained  on  two  source  documents;  the  Monthly  Training  and 
Readiness  Report  and  the  Monthly  Flight  Hour  Report.  Ztrax  is 
run  concurrently  from  within  the  Paradox  program  to  permit  a 
vast  array  of  ad  hoc  queries,  reports  and  the  importation  of 
graphical  display  mechanisms. 
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I .  INTRODUCTION 


The  fulfillment  of  the  information  needs  of  the  U.S.  Navy 
is  critical  to  attaining  continued  tactical  superiority  above, 
on  and  below  the  surface  of  the  oceans.  The  realization  of 
these  needs  constitutes  a  variety  of  scenarios  ranging  from 
the  real-time  update  of  mission  critical  information  to  the 
analysis  of  the  training  and  readiness  records  of  a  unit. 
Recent  and  predicted  future  reductions  in  appropriated  funding 
magnifies  the  need  for  comparative  analysis  of  training  and 
readiness  at  all  levels  of  operational  command.  To  effectively 
and  efficiently  prepare  the  Navy  for  future  encounters  with 
hostile  forces  we  must  employ  information  technology  to  supply 
the  systems  and  software  able  to  produce  timely  and  accurate 
information. 

Specific  measures  of  unit  tjraining  and  readiness  provide 
the  means  to  evaluate  a  squadron,  airwing  or  fleet's  ability 
to  complete  its  assigned  tactical  mission.  The  majority  of 
minor  commands,  i.e.,  airwings,  rely  on  manual  methods  to 
extract  relevant  information  from  a  myriad  of  data,  maintained 
as  it  is  received,  in  hard  copy  message  format.  Answering 
routine  queries  is  often  time  consuming  and  frequently 
unsuccessful.  This  situation  can  be  remedied  by  the 
implementation  of  a  database  management  system  (DBMS)  utilizing 
a  user  friendly,  commercially  available  relational  database 
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software  application (RDBMS) .  Once  the  RDBMS  is  operational, 
specific  local  user  requirements  can  be  identified.  There  are 
typically  several  repetitive  database  queries  which  will  aid 
in  the  construction  or  use  of  a  decision  support  system (DSS) . 
Of  vital  importance  to  the  users  is  the  ability  to  attain  and 
interpret  data  and  information  quickly  and  efficiently  without 
a  tedious  and  time  consviming  process.  This  will  be  accomp¬ 
lished  through  the  implementation  of  a  DSS. 

A.  BACKGROUND 

The  mission  of  a  Fleet  Patrol  Wing  is  to  guide  and  direct 
the  organization,  administration,  and  training  of  all  patrol 
squadron  (VP)  forces  subordinate  to  it  (COMPATWINGSPAC,  1988) . 
Specific  responsibilities  include: 


•  Operational  control  functions  of  air  Anti-submarine 
warfare (ASW)  units  assigned  to  a  Fleet  Commander. 

•  Supervise  and  coordinate  patrol  squadron  training. 

•  Investigate  and  recommend  improvement  in  ASW  training, 
tactical  doctrine,  and  equipments. 

•  Establish  performance  and  readiness  standards  and 
evaluates  the  readiness  of  subordinate  squadrons . 

•  Conducts  inspections  of  patrol  wings,  stations  and 
squadrons . 

•  Directs  aircraft  maintenance  practices,  procedures  and 
doctrine  in  subordinate  squadrons  with  a  view  of  promoting 
maximum  efficiency. 

•  Exercises  military  control  of  assigned  forces  in  the 
execution  of  operational  ASW  and  surveillance  missions  and 
tasks  (COMPATWINGSPAC,  1988) . 


2 


Several  departments  within  the  organizational  s'  ructure  of 
an  airwing  retain  functional  responsibility  for  the  areas 
listed  above.  They  include: 

•  Operations 

•  Tactics  Development  and  Evaluation (Tac  D&E) 

•  Readiness  and  Training  Plans 

•  Manpower  and  Personnel 

•  Maintenance 

The  departments  deriving  the  majority  of  the  benefit  from 
ZTRAX  are  Operations  and  Readiness  and  Training  Plans.  The 
requirement  for  timely  readiness  and  training  information 
presented  in  a  desirable  format  is  an  increasingly  difficult 
and  time  consuming  task.  Numerous  man-hours  are  spent  in 
daily  activities  to  satisfy  the  current  needs.  ZTRAX  will 
serve  to  meet  the  present  needs  and  those  of  the  future. 

1.  Readiness  and  Training  Plans  Department  Operations 
The  readiness  and  training  plans  department  of  an 
airwing  is  a  cornerstone  to  the  efficient  operations  and 
readiness  stature  of  all  the  squadrons  over  which  it  maintains 
operational  control.  The  office  serves  as  a  collector  of  data 
and  disseminator  of  vital  information.  The  numerous  readiness, 
training  and  flight  hour  concerns  range  from  individual 
squadron  queries  for  comparative  mining  readiness  command 
inspection (MRCI)  flight  hours,  parent  airwing  requests  for 
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graphical  portrayals  of  monthly  aircrew  manning  levels  and 
pilot  training  and  proficiency  statistics  to  CNO  directed 
monitoring  and  maintenance  of  prescribed  combat  readiness 
levels.  Currently,  the  majority  of  the  training,  readiness 
and  specific  squadron  flight  hour  information  is  processed 
manually.  Gathering  pertinent  data  in  these  instances  is 
extremely  difficult  and  time  consuming  because  they  are  stored 
in  hard  copy  form  and  require  several  iterations  of  records 
search.  Other  departmental  operations  such  as  airwing- level 
flight  hours  and  OPTAR  budgets  are  tracked  utilizing  various 
commercial  spreadsheet  applications.  It  is  essential  ZTRAX 
have  the  ability  to  interact  with  those  applications, 

a .  Structure 

The  readiness  and  training  plans  department  is 
staffed  by  two  personnel,  a  post -patrol  squadron (VP) 
department  head  tour  Commander  who  serves  as  the  Readiness  and 
Training  Plans  Officer  and  a  Chief  Petty  Officer.  In 
addition,  two  civilian  administrative  assistants  are  available 
for  administrative  functions,  as  required.  The  Readiness 
Officer  reports  directly  to  the  Admiral's  Chief  of  Staff  on 
all  matters  concerning  the  department's  affairs. 

b.  Workload 

The  majority  of  data  processed  by  the  readiness 
department  is  received  via  message  format  from  the  operational 
squadrons  or  parent  organizations,  such  as  COMNAVAIRPAC,  where 
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they  originate.  Flight  hour,  OPTAR  and  future  detachment  and 
deployment  activity  data  pertaining  to  current  records  on  the 
existing  hardware  are  transferred  to  the  department, 
accordingly.  These  manual  data  transfers  and  subsequent 
queries  account  for  approximately  seventy  percent  of  the  daily 
departmental  operations.  OPTAR  updates,  tempo  of  operations 
and  various  queries  demand  numerous  hours  of  attention  each 
day,  primarily  due  to  the  inability  of  the  existing 
information  system  to  maintain  all  of  the  required  data. 
Periodic  reports  and  miscellaneous  information  services  and 
message  traffic  complete  the  required  departmental  activities. 

2 .  System  Evaluation  and  Functional  Requirements 

The  existing  hardware  consists  of  two  Z-248  processors 
with  the  standard  20  megabyte  hard  drive,  640Kb  of  RAM  and  a 
VGA  monitor.  These  systems  utilize  of  variety  of  commercially 
available  microcomputer  spreadsheet  and  database  software 
applications  to  store  and  access  information.  Presently,  hard 
drives  of  both  systems  are  completely  filled  data  required  to 
effect  daily  operations.  The  constraints  of  the  hard  drives 
capacity  have  necessitated  the  least  recent  data  being  removed 
from  memory  to  allow  new  data  to  be  entered  into  the  program. 
This  has  resulted  in  reports  and  graphical  portrayals  of 
information  that  are  incomplete  because  a  portion  of  the 
historical  data  had  to  be  removed  to  accommodate  the  new  data. 
The  hardware  currently  in  use  would  suffice  with  some  upgrades 


if  the  processing  needs  of  the  department  were  to  remain 
constant,  i.e.,  maintain  the  status  quo  of  tracking  and 
presenting  queried  readiness  and  training  information  via  the 
manual  means.  The  introduction  of  ZTRAX,  a  training, 
readiness  and  flight  hour  tracking  system,  has  drastically 
increased  the  memory  and  processor  speeds  required  to  most 
effectively  and  efficiently  utilize  the  designed  system  to  its 
utmost.  Several  alternatives  able  to  solve  the  aforementioned 
problems  exist: 

1 .  Upgrade  the  motherboard  to  a  faster  processor  capable  of 
providing  less  idle  time  during  query  processing. 

2 .  Augment  the  existing  hard  drive  with  a  larger  and  faster 
model  containing  a  disk  cache  able  to  provide  sufficient 
memory  and  fast  access  into  the  future. 

3.  Expand  the  random  access  memory (RAM)  from  the  current 
640Kb  to  at  least  two  megabyte.  This  will  allow  the  entire 
ZTRAX  program  to  exist  in  main  memory  during  database 
operations . 

4.  Replace  the  existing  system  with  a  current  GSA  contract 
model  386  machine  which  will  provide  satisfactory 
performance  well  into  the  future. 

The  most  desirable  solution,  as  shown  in  a  comparative 
analysis  of  options  contained  in  Chapter  V,  is  the  purchase  of 
two  Unisys  386  machines  per  the  current  GSA  Desktop  III 
contract  agreement. 

Functional  requirements  for  ZTRAX  were  based  on  the 
need  to  lessen  the  time  required  to  research  and  present 
information  currently  stored  in  hard  copy  form,  the 
requirement  to  use  the  Monthly  Training  and  Readiness  Report 
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and  Monthly  Flight  Hour  Report  as  source  documents  and  desired 
end-user  functionality.  They  are  as  follows: 


1.  Safely,  securely  and  reliably  maintain  data  and  records. 

2.  Provide  pre  defined  queries  of  frequently  requested  data 
fields,  i.e.  monthly  status  of  pilot/ crew  training.  Primary 
Mission  Area(PMA)  readiness  for  individual  squadrons  and 
parent  airwings  and  comparative  analysis  of  flight  hours. 

3 .  Provide  ad  hoc  query  capability  without  lengthy  and 
cumbersome  procedures. 

4.  Allow  graphical  interface  portrayals  with  Lotus  and 
Harvard  Graphics. 

5.  Provide  for  the  future  capability  to  update  records  on¬ 
line  with  floppy  disks  vice  the  current  system  of  manual 
entry. 

6.  Display  all  text  and  graphical  information  with  the 
option  to  produce  imiviediate  hard  copy. 

B .  RESEARCH  QUESTIONS 

This  thesis  will  address  the  following  questions: 


1.  Can  a  commercially  available  relational  database  software 
application  be  fully  utilized  to  accomplish  RDBMS  functions, 
such  as  ad  hoc  queries  and  graphical  output  portrayals,  in 
a  fast  and  efficient  manner  despite  the  computer  hardware 
constraints  held  by  operational  airwings? 

2.  What  are  the  specific  system  requirements  for  utilizing 
the  database  management  system  to  maximize  its  capabilities? 

3 .  Can  measures  be  implemented  to  enter  raw  training  and 
readiness  data  into  the  database  by  other  than  the  manual 
manipulation  of  the  tables  themselves? 

4.  Can  justification  be  given  to  replace  existing  computer 
hardware  systems  with  '^urrent  Unisys  GSA  contract  models  in 
order  to  meet  the  desired  performance  and  data  storage 
requirements? 
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C .  OUTLINE 


Chapter  II  will  detail  the  design  of  the  RDBMS. 

Chapter  III  discusses  implementation  of  the  RDBMS  and  its 
interaction  with  other  commercial  software  applications  for 
graphical  representation  purposes.  The  users  manual  is 
contained  in  Appendix  E. 

Chapter  IV  discusses  the  issue  of  computer  security  and 
its  relevance  to  all  microcomputer  operations. 

Chapter  V  provides  recommendations  and  conclusions  for  the 
use  of  a  relational  database  management  system  to  provide 
accurate  and  timely  readiness  and  training  information. 

Appendix  A-E  will  provide  the  data  input  documents,  object 
diagrams,  object  definitions,  domain  definitions  and  the  users 
manual,  respectfully. 
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II.  DESIGN 


Database  design  involves  several  significant  steps  which 
are  necessary  to  ensure  that  a  complete  and  conceptually 
correct  model  emerges.  Using  an  object  oriented  design 
approach,  the  first  step  is  to  identify  the  database  system 
requirements.  This  includes  identifying  the  objects  the  users 
require  to  effectively  track  their  data.  Next,  the  objects 
identified  in  the  requirements  phase  will  be  normalized  to 
ensure  they  support  the  requirements  of  the  users .  The 
normalization  process  gathers  data  items  into  relations  which 
are  not  redundant  and  can  be  manipulated  by  the  users  without 
the  threat  of  data  loss  due  to  modification  anomalies  (Dolan, 
1988)  . 

The  use  of  the  relational  data  model  for  ZTRAX  was 
predicated  on  the  conceptual  view  the  user  has  of  the  data 
objects  contained  within  the  system.  The  goals  of  the 
relational  model  are  twofold;  to  provide  data  independence  by 
identifying  the  separation  of  the  physical  format  from  the 
users  view  of  the  data,  and  to  achieve  data  integrity  by 
avoiding  data  inconsistencies  and  anomalies  in  the  processing 
of  the  data  itself  (McClanahan,  1991) . 


The  view  of  the  system  that's  provided  by  the  (relational) 
data  model  describes  the  structure  of  the  data  in  a 


natural  form  that  the  users  can  intuitively  understand 
without  extensive  training  (McClanahan,  1991) . 

The  users  in  the  readiness  and  training  plans  department, 

having  little  or  no  experience  with  database  operations,  will 

benefit  from  the  architecture  of  this  model. 

A.  REQUIREMENTS  DEFINITION 

The  basis  of  the  design  of  ZTRAX  revolves  around  two 
monthly  reports,  the  Monthly  Training  and  Readiness  Report 
message  and  the  Monthly  Flight  Hour  Report  message,  depicted 
in  Appendix  A  as  source  documents.  These  reports  are 
transmitted  to  the  airwing  by  the  originating  squadron  by  no 
later  than  the  fifth  day  of  each  month  and  provide  relevant 
data  from  the  previous  month's  operations.  The  standardized 
format  and  fixed  field  length  of  the  reports  will  allow  for 
future  updates  of  records  via  floppy  disk.  The  attributes  and 
objects  identified  for  ZTRAX  are  derived  from  these  reports. 

1.  Objects 

Objects  are  defined  as  a  collection  of  properties  that 
describe  an  entity  in  the  users  work  environment.  All  objects 
have  a  name  which  corresponds  to  the  entity  it  represents. 
They  can  represent  items  such  as  an  inventory  item,  an 
operational  flight  hour  category  or  a  monthly  readiness 
report.  Each  object  property  must  represent  specific 
characteristics  of  the  real-world  entity  that  is  important  to 
the  users  of  the  database.  The  object  properties  must  provide 
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a  sufficient  description  of  the  true  entity  the  users  need  to 


have  represented.  An  entity  is  something  perceived  by  the 
user  as  a  single  independent  unit  capable  of  existing  on  its 
own.  The  database  is  a  collection  of  instances  of  objects, 
that  is  a  representation  of  one  specific  entity  (Dolan,  1988) . 

The  objects  and  their  respective  properties  were 
created  for  ZTRAX  through  a  hybrid  design  approach.  Sample 
source  docioments,  i.e.  the  Monthly  Training  and  Readiness 
Report  and  the  Monthly  Flight  Hour  Report,  and  end-user 
requested  data  input  and  output  displays  justified  the  object 
oriented  design  by  verifying  the  users  view  and  perception  of 
the  data  entities.  End-user  involvement  during  the  design 
phase  is  expected  to  result  in  an  easing  of  the  initial 
training  required  to  use  the  database  because  the  users  are 
familiar  with  the  objects,  their  functions  and  meanings. 
Appendices  B,  C,  and  D  provide  graphical  views  of  the  objects, 
object  definitions  and  domain  definitions,  respectively. 


1,  DETOPS  Object  represents  the  detachment  operations  during 
a  report  month  and  pertains  to  both  source  documents .  This 
object  provides  the  detachment  name,  site  and  type,  dates  of 
detachment,  total  flight  hours,  number  of  aircraft,  aircrews 
and  days.  The  objects  ID  and  a  subset  of  the  multiple 
valued  FLTHRS  object,  category,  are  also  contained  in 
DETOPS . 

2.  FLTHRS  Object  represents  the  various  types  of  flights  and 
flight  hours  performed  by  an  operational  squadron.  It 
provides  a  category  name,  area  name,  type  name,  and  specific 
type  as  they  pertain  to  both  source  documents.  The  objects 
ID  and  MATRIX  are  included  within  FLTHRS. 
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3.  FLTRPT  Object  represents  the  monthly  flight  hour  report 
source  document  shown  in  Appendix  A.  It  contains  the  ID 
object,  the  multiple  valued  FLTHRS  object,  the  PILOT  STATS 
object,  the  multiple  valued  INST  PILOTS  object  and  the 
multiple  valued  DETOPS  object. 

4.  ID  Object  represents  the  key  identifying  attributes  of 
the  database.  They  are:  squadron  number  which  identifies  a 
specific  squadron,  month  which  identifies  the  report  month, 
year,  report  type  which  identifies  the  source  document  where 
the  data  originates  and  squadron  status  which  indicates 
whether  the  squadron  is  home  or  deployed  during  the  report 
month. 

5.  INST  PILOT  Object  represents  instructor  pilot  data 
contained  only  on  the  monthly  flight  hour  report.  It 
consists  of  rank  which  identifies  military  rank,  date  of 
designation  as  an  instructor  pilot  and  predicted  rotation 
date  of  the  instructor  pilot.  The  ID  object  is  included 
within  INST  PILOT. 

6.  MANNING  Object  represents  designated  aircrew  manning 
levels  within  a  squadron  for  a  report  month.  It  is  specific 
to  the  monthly  Training  and  Readiness  report.  Manning 
consists  of:  position  name  which  identifies  the  aircrew 
position,  total,  gains  and  losses  which  give  numeric 
indications  of  the  manning  levels  for  a  specific  position, 
cat  I/II  or  III  which  categorize  officer  sea  tours  and  the 
ID  object. 

7.  MATRIX  Object  represents  various  entities  relating  to 
specific  flights  and  flight  hours.  This  object  is  specific 
to  the  monthly  Flight  Hour  report  and  includes:  sorties 
which  indicate  the  number  of  missions  flown  for  a  particular 
category,  area,  type  or  specific  type,  onstation  which 
indicates  the  flight  hours  onstation  during  a  sortie,  total 
flight  hours  for  the  mission  and  contingency  which  is  a 
numeric  count  of  the  number  of  those  missions  flown.  The 
FLTHRS  object  is  included  in  the  MATRIX  object. 

8.  NIGHTHRS  Object  represents  the  night  flight  hours  flown 
by  a  squadron  during  a  report  month  and  is  specific  to  the 
Training  and  Readiness  report.  It  contains  night  hours, 
night  hours  as  a  percent  of  total  hours  and  the  ID  object. 

9.  PILOT  STATS  Object  represents  first  tour  pilot  statistics 
and  is  specific  to  the  Flight  Hour  report.  It  contains  the 
average  first  pilot  time  for  first  tour  pilots,  number  of 
pilots  not  acquiring  ten  hours  of  first  pilot  time  and  PEF 
pilots.  The  ID  object  is  also  represented. 


12 


10.  RDYRPT  Object  represents  the  monthly  Training  and 
Readiness  report  and  is  comprised  solely  of  the  following 
objects:  ID,  multiple  valued  MANNING,  multiple  valued  R- 
LEVELS,  multiple  valued  FLTHRS,  multiple  valued  DETOPS  and 
NIGHTHRS . 

11.  R- LEVELS  Object  represents  the  combat  readiness  levels 
attained  by  a  squadron's  aircrews,  in  various  categories, 
during  the  report  month.  R-LEVELS  is  specific  to  the 
monthly  Training  and  Readiness  report  and  contains  primary 
mission  area(PMA)  names,  C-rating  which  is  an  assigned 
rating  for  a  PMA  dependent  upon  the  number  of  aircrews  in  a 
squadron  designated  as  combat  ready,  number  of  aircrews 
designed  C-l(the  highest  level)  and  the  percentage  of  crews 
rated  C-1  to  the  total  number  of  crews  in  a  squadron.  The 
ID  object  is  also  contained  with  this  object. 


Each  of  the  above  objects  is  essential  to  accurately 
represent  the  users  view  of  the  data  in  a  relational  database 
model.  It  was  possible  in  some  instances  however,  to  utilize 
a  single  object  to  represent  duplicate  data  contained  in  both 
reports,  thereby  eliminating  any  data  redundancy.  The  DETOPS 
Object  and  FLTHRS  Object  reflect  similar  data  found  in  both 
source  documents.  An  attribute  of  the  ID  Object,  report  type, 
will  insure  proper  identification  and  placement  of  similar 
data  elements  found  in  these  two  objects. 

2 .  Functional  Components 

The  functional  components  of  a  database  include  the 
flow  of  data  and  information  and  the  necessary  update,  display 
and  control  mechanisms  which  keep  the  database  information 
current  and  accessible. 

The  ZTRAX  tracking  application  is  a  simple  model  of 
data  flow  and  retrieval.  All  input  data  is  received  by  the 


Training  and  Readiness  Plans  department  via  message  from 
operational  squadrons.  The  format  and  guidance  for  the 
monthly  messages  are  two  airwing  originated  instructions, 
COMPATWINGSPAC  3500.1  AND  COMPATWINGSPAC  3500. 2 7A.  Upon 
receipt  of  the  monthly  Training  and  Readiness  and  Flight  Hour 
messages,  department  personnel  enter  all  the  data  contained  on 
them  into  the  database.  Reports  and  graphic  depictions  of 
data  are  generated  as  required  in  response  to  ad  hoc  queries 
made  by  the  department,  squadrons.  Chief  of  Staff  or  Admiral. 
Presently,  the  department  is  not  required  to  submit  any 
recurring  reports  that  contain  data  which  will  originate  from 
the  ZTRAX  database  tables.  The  implementation  of  ZTRAX  will 
provide  the  users  the  capability  to  do  so  in  the  future. 

B.  NORMALIZATION 

Normalization  involves  the  gathering  of  data  items  or 
properties  into  relations.  Objects  are  used  in  the 
normalization  process  because  they  represent  groups  or  related 
data  items.  The  goal  of  normalization  is  to  provide  a 
representation  of  the  user  defined  objects  in  the  database  by 
using  relations  that  provide  the  necessary  data  to  construct 
the  user  objects  and  are  able  to  allow  rows  of  data  to  be 
inserted,  deleted  or  modified  without  inconsistencies  or 
errors  resulting  (Dolan,  1988) . 

The  first  step  in  the  normalization  process  is  the 
elimination  of  modification  anomalies.  They  can  result  in  the 
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elimination  of  existing  data  in  the  database,  a  deletion 
anomaly.  The  inability  to  enter  a  fact  about  one  entity  until 
another  entity  has  been  entered,  an  insertion  anomaly.  ZTRAX 
does  not  contain  either  of  these  anomalies  in  it's  design. 

Relations  can  be  classified  by  the  types  and  classes  of 
anomalies  they  may  contain.  The  techniques  for  preventing 
these  anomalies  are  called  normal  forms  and  proceed  from  first 
to  fifth.  Normal  forms  identify  the  relationships  among 
attributes,  functional  dependencies  and  key  fields  of  the 
relations  and  seek  to  resolve  the  modification  anomalies. 
Normalization  of  the  relations  is  an  essential  step  in  the 
logical  design  of  a  database.  Capturing  the  user's  view  is 
essential  to  the  successful  design  and  implementation  of  a 
relational  database  management  system.  Object  specifications 
for  ZTRAX  were  defined  by  completing  a  thorough  systems 
analysis  to  establish  the  exact  requirements  and  constraints 
the  database  must  meet.  Background  information  identified  the 
smallest  useable  data  elements,  known  as  attributes,  and 
grouped  them  into  entities  which  formed  the  basis  for  the 
tables  in  ZTRAX.  This  design  method  has  insured  ZTRAX  will 
provide  sharable  data  and  information,  assure  integrity  and 
evolve  with  the  growth  of  the  organization  (Bagchi,  1987) . 
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III.  IMPLEMENTATION 

Database  implementation  is  an  on-going,  iterative  process. 
It  involves  much  more  than  the  installation  of  the  application 
and  user  training,  rather  it  is  the  complete  and  thorough 
commitment  to  an  adaptive  maintenance  plan  which  involves 
database  administration  guidelines,  back-up  and  recovery 
procedures,  database  housekeeping  and  future  enhancement 
considerations . 

A.  INSTALLATION 

The  installation  procedures  for  ZTRAX  are  quick  and  simple 
to  accomplish.  Because  ZTRAX  runs  best  from  within  Paradox, 
the  first  step  is  to  create  a  subdirectory  named  ZTRAX.  Next 
make  a  back-up  copy  of  each  ZTRAX  program  disk.  Store  the 
original  ZTRAX  disks  in  a  safe  place  and  continue  with  the 
installation  process  using  the  back-up  copies.  To  continue, 
insert  ZTRAX  disk  one  into  the  A  drive  and  copy  the  entire 
contents  into  the  ZTRAX  subdirectory  of  the  hard  drive. 
Repeat  this  step  for  the  remainder  of  the  ZTRAX  disks.  ZTRAX 
is  now  installed  on  the  system.  To  initiate  ZTRAX,  use  normal 
start  up  procedures  for  Paradox.  When  the  Paradox  main  menu 
appears,  select  TOOLS  and  change  the  directory  to  ZTRAX.  This 
allows  the  standard  query,  report  and  graphic  functions  of 
Paradox  to  be  used  by  the  ZTRAX  tables  without  changing 
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directories  later.  Now  you  can  run  the  ZTRAX  application 
through  Paradox  by  selecting  the  SCRIPT/PLAY  option  of  the 
main  menu  and  entering  ZTRAX  at  the  prompt.  At  this  point  the 
ZTRAX  main  menu  will  appear  and  data  entry,  edit  or  view 
(query)  are  selectable.  The  specific  use  of  these  ZTRTUC 
options  are  contained  in  the  users  manual  (Appendix  F) .  To 
maximize  the  capabilities  of  ZTRAX,  all  users  of  this  appli¬ 
cation  should  be  familiar  with  standard  Paradox  operations. 

B .  TRAINING 

An  operator  training  program  for  ZTRAX  should  accompany  an 
on-going  program  designed  to  maximize  the  potential  uses  of 
Paradox.  As  a  stand  alone  application  ZTRAX  successfully 
accomplishes  its  designed  task,  to  provide  a  repository  of 
readiness  and  flight  hour  data  which  is  easily  accessible  and 
manipulable.  However,  optimizing  the  data  contained  in  ZTRAX 
is  best  accomplished  with  ad  hoc  queries  through  the  use  of 
Paradox  and  its  multiple  functions.  For  users  to  excel  at 
using  ZTRAX,  they  must  first  feel  comfortable  in  the  Paradox 
operating  environment.  User  training  in  Paradox  can  be 
obtained  many  ways.  First,  Paradox  offers  an  extremely 
thorough  and  instructive  help  menu  which  is  accessible  from 
any  Paradox  screen  at  any  time.  These  help  tips  and  screens 
benefit  all  levels  of  users  by  explaining  keystrokes,  query 
forms,  reports,  etc.,  then  showing  examples  of  the  proper 
format  for  the  command  in  question.  Second,  Paradox  offers  an 
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on-line  tutorial  program  designed  to  teach  basic  database 
operations  to  the  inexperienced  user.  It  contains  a  program 
which  walks  new  users,  step  by  step,  through  creating, 
editing,  printing  and  querying  tables.  The  use  of  this 
tutorial  is  essential  for  first  time  users  of  Paradox.  It 
will  provide  the  necessary  baseline  of  knowledge  required  to 
utilize  Paradox  for  effective  database  operations. 

Training  in  the  use  of  the  ZTRAX  application  should  occur 
after  a  working  knowledge  of  Paradox  techniques  have  been 
obtained.  The  ZTRAX  program  is  completely  menu  driven  with 
explanations  of  each  screen  display  located  below  various  menu 
choices.  The  most  effective  training  method  for  learning 
ZTRAX  is  hands  on  experience  with  the  menu  system.  All  of  the 
menus  and  screen  displays  are  similar  to  the  source  documents 
they  represent  to  ease  the  initial  training  required  for  first 
time  users  of  the  program.  Although  knowledge  of  Paradox  is 
necessary  to  fully  utilize  ZTRAX,  a  user  unfamiliar  with 
Paradox  or  ZTRAX  could  enter  new  data  with  very  little 
training.  This  an  important  future  consideration  for  ZTRAX 
because  its  use  in  a  squadron  environment  will  not  allow  for 
extensive  user  training  prior  to  implementation.  Data 
add/edit  procedures  in  their  present  form  will  allow  junior 
enlisted  squadron  personnel  to  enter  data  with  a  small  amount 
of  training.  This  serves  an  important  purpose  by  freeing 
senior  personnel  from  the  time  intensive  burden  of  data 


18 


entry/edit  and  allows  them  the  freedom  to  query  the  database 
based  on  their  needs. 

C.  DATABASE  ADMINISTRATION 

Administrative  control  of  the  database  will  be  under  the 
direction  of  the  Readiness  and  Training  Plans  Officer.  His 
responsibilities  currently  include  maintaining  hard  copy  of 
the  data  and  providing  information  drawn  from  it.  Therefore, 
as  department  head,  he  has  the  greatest  interest  in  duties 
which  would  normally  be  performed  by  a  database  administrator 
(DBA)  for  this  application.  The  duties  of  a  DBA  are  wide  and 
varied,  dependent  upon  the  size  and  type  of  database 
application  that  is  being  run.  For  ZTRAX,  the  necessary 
administrative  tasks  are  very  specific  because  it  is  a 
relatively  small  application. 

The  first  priority  of  the  DBA (department  head)  for  ZTRAX 
is  the  security  of  the  database  and  the  system  which  contains 
it.  The  two  microcomputers  located  in  the  department  exist  at 
the  present  time  with  no  physical  security  devices  to  prohibit 
entry  into  the  system.  A  security  plan  including  physical  and 
data  security  measures  must  be  instituted  to  preserve  the 
integrity  of  the  system  and  database,  should  an  intrusion 
occur.  The  plan  should  be  clear  and  concise  as  to  which  users 
are  authorized  access  and  where  they  are  allowed  to  travel 
once  logged  on  to  the  system.  Chapter  IV  provides  a  security 
site  survey  of  the  department  and  makes  specific 
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recommendations  for  the  initiation  of  a  security  program  for 
the  ZTRAX  database  and  the  department's  Z-248  computers  it  is 
currently  run  on. 

The  second  priority  of  the  DBA  is  the  assurance  that  the 
users  are  receiving  the  information  they  require.  This  is 
accomplished  two  ways.  First,  a  periodic  review  of  the  source 
documents  will  identify  any  changes  in  the  necessary  input 
data.  If  a  change  does  occur,  it  will  be  the  responsibility 
of  the  DBA  to  modify  the  input,  edit  and  pre- defined  query 
screens  found  in  ZTRAX.  These  procedures  are  given  in  the 
maintenance  section  of  the  ZTRAX  users  manual.  Second, 
determining  if  users  are  receiving  the  information  and  support 
they  require.  If  they  are  not,  trav  ’  ,.j  with  Paradox  and  the 
specific  functions  the  vters  require  can  alleviate  their 
dissatisfaction  and  provide  new  avenues  to  more  effective  and 
efficient  use.  In  this  instance  the  DBA  must  recognize  the 
need  for  greater  user  involvement. 

The  third  priority  of  the  DBA  is  the  management  and 
allocation  of  disk  space  used  by  the  ZTRAX  database  tables  and 
related  files.  As  it  stands,  the  ZTRAX  program  accounts  for 
1.8  megabytes  of  memory  usage  on  the  hard  drive.  Each  Monthly 
Training  and  Readiness  report  record  takes  up  approximately 
500  bytes  of  memory  and  a  Monthly  Flight  Hour  Repoit  about 
1500  bytes.  This  total  of  2000  bytes,  or  2Kb,  accounts  for 
one  squadron's  data  input  for  a  month.  For  the  nine  squadrons 
under  the  operational  control  of  the  airwing  the  total  monthly 
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data  input  to  ZTRAX  and  stored  on  the  hard  drive,  about  l8Kb. 
By  today's  standards,  this  is  a  small  amount  of  disk  space  to 
be  concerned  with,  however,  the  hardware  constraints  on  the 
existing  microcomputers  at  the  airwing  make  this  a  serious 
problem. 

The  ii  icrocomputers  in  the  department  are  Z-248's  with  20 
megabyte  hard  disks.  When  ZTRAX  was  installed  the  available 
hard  disk  capacity  dropped  to  below  one  megabyte.  That 
translates  to  four  years  of  input  data  assuming  no  other  data 
is  stored  from  any  of  the  various  spreadsheet  and  word 
processing  programs  existing  on  the  same  computer. 

First,  how  much  historical  data  is  required  to  provide  an 
accurate  picture  of  training,  readiness  and  flight  hour 
statistics  for  a  squadron  or  airwing?  At  the  present  time, 
the  department  maintains  copies  of  all  the  monthly  reports 
from  all  the  squadrons  for  a  period  of  three  years  following 
its  transmittal.  With  the  current  situation  of  available 
memory,  three  years  of  data  would  take  approximately  650Kb  of 
space,  effectively  filling  the  hard  disk  to  capacity  without 
room  for  any  other  data  storage.  Two  years  of  data  would, 
however,  provide  an  entire  18  month  operating  cycle  for  a 
squadron  plus  six  months  overlap  for  any  contingencies.  This 
18  month  training/deployment  cycle  is  the  basis  for  the  data 
analysis  of  the  optimal  training  and  readiness  posture  done  in 
the  department . 
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If  a  constant  historical  record  of  the  two  previous  years 
is  to  be  maintained  on  the  hard  disk,  then  older  records  must 
be  archived  prior  to  deletion.  Archiving  the  data  allows  more 
working  space  on  the  hard  disk  and  provides  several  years  of 
historical  data.  If  the  requirement  for  historical  data 
arises,  the  archived  data  can  be  loaded  into  a  floppy  drive 
and  queried  without  reloading  to  the  hard  disk.  The  best  way 
to  archive  is  to  copy  specific  records  to  floppy  disk  as  they 
are  entered  as  new  data.  This  prevents  accidental  deletions 
two  years  from  now  when  the  data  is  to  be  deleted  and  provides 
an  additional  backup  copy  of  the  database  records.  The  use  of 
the  Paradox  copy  command  provides  the  means  to  copy  data 
record  by  record,  which  is  required  here.  The  ZTRAX  users 
manual  describes  the  use  of  this  command  for  disk  backup 
procedures,  any  further  reference  to  the  copy  function  ir? 
contained  in  the  Paradox  users  manual . 

Consistent  with  the  memory  management  problem  experienced 
with  ZTRAX  records  is  the  lack  of  archiving  and  backup  records 
for  the  various  other  applications  contained  on  the 
department’s  computers.  Although  beyond  the  scope  of  this 
thesis,  an  internal  evaluation  of  the  historical  record 
storage  requirements  for  each  application  should  be  made  to 
identify  possible  solutions  to  this  problem. 

Backup  and  recovery  procedures  are  an  integral  part  of 
any  database  administration  plan.  The  ability  to  recover 
sensitive  data  in  the  event  of  system  failure  can  save 
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hundreds  of  hours  attempting  to  manually  recover  lost  records. 
The  department's  information  system  consists  of  two  stand 
alone  microcomputers  which  operate  solely  in  a  transaction 
processing  mode.  For  this  reason,  data  and  record  backup 
procedures  should  be  instituted  following  every  new  data  entry 
and  edit.  This  will  ensure  a  backup  disk  library  which  always 
contains  newly  added  data  and  records.  Procedures  for  backup 
and  recovery  are  contained  in  section  one  of  the  ZTRAX  users 
manual  and  make  use  of  the  Paradox  copy  command. 

Database  housekeeping  is  another  duty  of  the  DBA.  It 
involves  a  variety  of  routine  maintenance  tasks  which  keep  the 
system  operational  and  accessible.  Users  in  particular 
benefit  from  a  housekeeping  program  which  is  attentive  to 
their  needs.  Several  of  the  activities  already  discussed, 
such  as  backup  and  archive  copies  of  data,  updating  program 
files  and  persistent  user  training  all  comprise  an  effective 
data  housekeeping  plan.  The  following  section  describes 
another  important  DBA  function,  future  considerations  and 
updates  for  the  ZTRAX  application. 
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D.  FUTURE  PROGRAM  CONSIDERATIONS 

As  essential  to  maintaining  program  integrity  by  making 
backup  and  archive  copies  of  disks  is  the  continuing  program 
of  perfective  maintenance  for  data  entry,  edit  and  query. 
Perfective  maintenance  involves  the  redefinition  of  tables, 
screens,  input  and  output  displays.  As  the  ZTRAX  application 
becomes  more  familiar  to  users  they  will  progressively  request 
more  from  it .  The  manipulation  of  the  Paradox  program  can 
answer  many  of  these  requests,  primarily  from  the  standpoint 
of  ad  hoc  queries,  but  data  add  and  edit  is  a  ZTR7\X  function. 

There  are  two  situations  where  a  change  to  the  ZTRAX 
tables  and  associated  input /edit  screens  would  be  necessary. 
First,  a  change  to  the  source  documents  would  require  an 
amendment  to  the  tables.  Second,  user  requests  for  modified 
data  entry  screens  and  forms.  Both  instances  are  covered  in 
section  six  of  the  ZTRAX  users  manual  (Appendix  F) . 

The  largest  concern  relative  to  these  two  situations 
described  above  is  changing  the  fields  in  a  table  and  hence 
their  format.  If  a  new  field  is  added  to  a  table,  the 
associated  input  form  must  also  have  that  field  added  to  it  or 
there  will  be  no  way  to  add  the  data  from  the  new  field  into 
ZTRAX.  This  is  a  simple  procedure  which  is  described,  with  an 
example,  in  section  six  of  the  users  manual.  Changing  the 
format  of  the  table  also  affects  the  archive  procedure  already 
discussed.  To  use  the  Paradox  add  command  to  archive  records 
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the  tables  must  be  of  compatible  format.  In  order  to  preserve 
the  older  records  and  save  the  new  ones  it  will  be  necessary 
to  create  a  new  archive  file  for  the  newly  formatted  table. 
Queries  of  archived  historical  data  using  the  floppy  drives 
will  still  be  possible,  only  slower  because  Paradox  will  be 
required  to  search  multiple  files  for  data  instead  of  one. 

Modifying  input,  edit  and  query  screens  for  the  purpose  of 
user  satisfaction  is  also  covered  in  section  six  of  the  users 
manual.  These  procedures,  however,  have  no  effect  on  the 
existing  structure  of  the  tables.  Therefore,  archiving  can 
take  place  normally.  Paradox  also  offers  several  utilities 
which  allow  the  user  to  customize  the  Paradox  application 
based  on  their  needs.  Screen  colors,  default  directories, 
protected  tables  and  several  others  are  available  for  use  and 
manipulation  by  the  DBA.  The  Paradox  users  manual  is  an 
excellent  source  of  knowledge  for  the  various  utilities 
available  and  their  requirements. 

Another  future  consideration  for  ZTRAX  is  the  automatic 
update  of  the  database  tables  with  floppy  disk  file  transfer, 
vice  the  current  method  of  manual  entry.  Paradox  offers  a 
unique  utility  designed  to  address  this  situation.  FLIMPORT, 
as  Paradox  refers  to  the  it,  creates  or  updates  tables  from 
fixed-length  ASCII  format  records.  This  utility  is  signifi¬ 
cant  because  it  can  transfer  files  either  singly  or  in  a  batch 
processing  mode.  The  files  from  the  floppy  disk  are  first 
copied  into  an  import  specification  file  designed  to  represent 
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the  table.  Next,  the  specification  file  transfers  the  new 
data  fields  into  the  appropriate  ZTRAX  table.  The  activation 
of  this  utility  would  divert  the  time  required  to  manually 
enter  the  new  data  in  ZTRAX  to  other  activities  and  suspend 
any  requirement  to  correct  errors  in  the  database  caused  by 
human  data  entry  error. 

To  take  advantage  of  the  capabilities  of  the  FLIMPORT 
utility,  the  local  communications  center  would  be  required  to 
place  a  Monthly  Training  and  Readiness  Report  or  Flight  Hour 
Report  message  for  each  squadron  onto  a  floppy  disk.  The 
message  would  already  be  formatted  in  fixed- length  ASCII 
characters,  therefore  no  file  conversion  would  be  required. 
The  communications  center  need  only  to  place  the  two  different 
messages  in  separate  directories  on  the  disk.  The  files  for 
each  type  of  message  v*'Ould  be  identified  by  squadron  number. 
When  the  hard  copy  messages  are  delivered  to  the  airwing  the 
floppy  disk  could  be  delivered  as  well.  The  capability 
currently  exists  at  some  communications  centers  to  deliver 
messages  on  floppy  disk  in  a  fixed  field  length  ASCII  format, 
unfortunately,  it  is  not  a  standardized  procedure  and  subject 
to  special  circumstances.  Further  information  on  FLIMPORT  is 
available  in  the  Paradox  users  manual  and  in  section  seven  of 
the  ZTRAX  users  manual . 
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IV.  SECURITY 


Microcomputer  security  measures  are  essential  to  control 
and  insure  the  integrity  of  the  database.  From  the  standpoint 
of  national  security,  any  information  system  such  as  ZTRAX, 
used  to  store  or  process  data  that  is  classified  presents  a 
potential  risk.  There  are  several  methods  to  effectively 
manage  the  security  of  a  system  and  its  components. 
Personnel,  data,  software,  and  hardware  controls  can  all  be 
implemented  to  reduce  the  risks  associated  with  any  operating 
environment . 

Regardless  of  any  protective  measures  in  place,  the 
key  element  to  security  in  any  microcomputer 
environment  is  the  user  and  how  well  the  user  follows 
the  established  computer  security  policies  and 
guidelines.  It  cannot  be  overemphasized  that  users 
are  the  ones  who  help  to  ensure  that  the  environment 
is  as  secure  as  necessary  (NAVCOMTELSTA,  1991) . 

Database  security  violations  are  defined  as  unauthorized 

access,  modifications,  readings  or  destruction  of  data  or 

information.  Threats,  either  malicious  or  accidental,  to  the 

system  can  occur  both  overtly  and  covertly.  The  following  are 

security  threats  to  the  various  entities  of  a  database 

environment  (NCTAMS  LANT  1991) . 

1.  Database  -  Unauthorized  access.  Copying,  Theft, 
Destruction 

2.  Hardware  -  Failure  of  protection  mechanisms. 
Contributions  to  software  failure 
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3.  Systems  Software  -  Failure  of  protection  mechanisms, 
Information  leakage 

4.  Operator  -  Duplication  of  reports.  Theft  of  classified 
material.  Fraudulent  identification  and  input  (NCTAMS  LANT 
1991)  . 

There  are  no  entities  involving  the  database  and  system 
components  that  preclude  the  use  of  security  controls  to 
maintain  system  integrity. 

A.  BACKGROUND 

SECNAVINST  5239.2  delineates  the  objectives  for  the 
Department  of  the  Navy  Automated  Information  System (AIS) 
security  program.  They  include: 

•  Preventing  fraud  and  abuse  by  implementing  the  necessary 
personnel,  hardware,  software  and  data  controls 

•  Ensuring  the  availability  of  reliable  information/ 
automated  support 

•  Protecting  AIS  resources  from  damage,  misuse  and  theft 

•  Accrediting  and  triennially  reviewing  all  AIS  through  a 
comprehensive  program  supported  by  certification  and  risk 
management  (NCTAMS  LANT,  1991) . 

Of  the  above  objectives,  an  initial  assessment  of  the  risks 
involved  with  the  local  operating  environment  are  the  first 
priority.  Risk  management  is  a  process  involving  the 
identification,  measurement  and  minimization  of  undesirable 
events  which  affect  all  AIS  resources.  It's  purpose  is  the 
reduction  of  system  risk  to  the  lowest  level  of  practicality 
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and  cost  effectiveness  while  consistently  remaining  within 
mission  criticality  requirements  (NCTAMS  LANT,  1991) . 

The  DON  risk  management  process  involves  several  distinct 
elements,  all  of  which  are  necessary  to  complete  an  accurate 
evaluation  of  a  commands  AIS  risks.  The  elements  of  the  risk 
management  process  are: 


•  AIS  Security  Survey  -  Collecting  basic  information  to 
assess  existing  security  posture 

•  Activity  AIS  Security  Plan  -  Planning  for  security  program 
implementation 

•  Risk  Analysis  -  Analyzing,  quantifying  and  counter  risks 
which  pertain  to  the  local  activity 

•  Contingency  Plan  -  Planning  for  disaster  recovery 

•  Security  Test  and  Evaluation  -  Testing  the  effectiveness 
of  an  activity's  security  program 

•  Accreditation  Report  -  Compilation  of  accreditation 
documentation  in  satisfaction  of  local  and  DON  guidelines 
(NCTAMS  LANT,  1991) . 


These  elements  pertain  to  all  types  of  AIS  and  include  word 
processors,  weapon  control,  communications  and  pertinent  to 
this  thesis,  microcomputers. 

B .  MICROCOMPUTER  SECURITY 

Security  concerns  in  a  non- complex  microcomputer  operating 
environment  are  wide  and  varied.  Data,  hardware,  software  and 
general  concerns  provide  a  combination  of  effectual  methods  to 
control  access  and  insure  a  stable  and  safe  AIS  work  space. 
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1 .  Data  Concerns 


Data  concerns  relate  to  daca  as  a  single  entity, 
independent  of  storage  media  on  a  microcomputer.  Access  to 
the  data  is  the  single  most  important  consideration  regarding 
security.  Data  access  controls  are  accomplished  several  ways, 
the  most  frequent  being  password  protection.  Within  the 
confines  of  a  database  environment,  a  hierarchical  structure 
of  passwords  can  be  used  to  help  control  authorized  and 
prevent  unauthorized  access. 

Other  data  concerns  are  the  nature  of  the  data  and  the 
media  protection  af^'orded  that  data.  Obviously,  classified 
data  should  on'' 7  re  accessible  to  those  authorized  users  with 
the  proper  f jcurity  clearance  and  the  need  to  know.  Ensuring 
the  proper  marking,  declassification  and  destruction  of 
magnetic  storage  media  will  prevent  any  security  violations 
from  occurring. 

2 .  Hardware  Concerns 

In  the  microcomputer  operating  arena,  the  hardware  in 
existence  today  does  not  contain  the  built-in  capability  to 
provide  internal  security  mechanisms.  The  theft  of  microcom¬ 
puters,  with  the  data  on  the  hard  disks  still  intact,  is  a 
burgeoning  criminal  activity  in  both  civilian  businesses  and 
government  agencies.  Denying  the  physical  access  to  micro¬ 
computers  to  anyone  except  authorized  users  can  help  prevent 
this  crime  from  occurring.  Measures  to  secure  the  machines  in 
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place  also  provide  a  high  degree  of  protection.  Using  locking 
cables  to  attach  microcomputer  bodies  to  desks  or  walls, 
storing  all  removable  magnetic  media  devices,  such  as  external 
hard  drives,  in  safes  or  locked  cabinets  and  locking  all 
offices  where  microcomputers  are  contained  can  all  deter  an 
attempted  theft  or  system  violation. 

3.  Software  Concerns 

Operating  system  and  software  application  controls  are 
the  best  way  to  deter  physical  access  to  restricted  data. 
Several  threats  exist  that  can  destroy  the  operating 
environment.  Software  attacks  by  hackers  and  intruders 
installing  virus  infections,  software  piracy  and  modifications 
to  existing  systems  and  data  can  all  suspend  your  ability  to 
operate  until  the  system  is  purged  of  any  foreign  material. 

Password  protection  is  a  viable,  yet  partial  solution 
to  the  software  security  dilemma.  It  is  available  on  DOS 
version  5.0,  WordPerfect,  Paradox  and  several  other  commer¬ 
cially  available  microcomputer  software  applications  which  are 
used  by  various  agencies  and  commands  in  the  Navy.  Passwords, 
if  used  only  at  the  entry  level  of  the  operating  system,  can 
help  provide  the  necessary  means  to  help  prevent  software 
security  incidents  and  accidents  from  occurring.  Encryption 
of  data  and  files  is  another  effective  method  to  prevent 
unauthorized  access.  When  used  in  conjunction  with  password 
protected  files,  data  encryption  provides  a  higher  level  of 
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security  and  access  restriction  to  the  operating  environment. 

4 .  General  Concerns 

Microcomputer  use  is  expanding  at  an  exponential  rate. 
More  users,  more  applications,  more  chances  for  fraud,  theft, 
damage  and  loss  to  occur.  One  of  the  most  serious  problems 
facing  the  micro  environment  is  the  lack  of  control  and  policy 
regarding  security  and  risk  management.  Continuous  user  and 
administrator  education  and  training  must  be  implemented  at 
all  levels  of  concern.  The  cost  is  inconsequential  when 
compared  to  the  loss  of  classified  or  sensitive  data  relevant 
to  national  security. 

C.  SITE  SECURITY  ISSUES 

The  ZTRAX  tables  will  contain  CONFIDENTIAL  data  once  the 
application  has  been  implemented  at  the  site.  It  is  primarily 
for  this  reason,  the  classified  nature  of  the  data,  that 
security  measures  must  be  taken  to  avoid  any  undue  risks  of 
compromising  the  integrity  of  the  database.  Contained  on  the 
same  microcomputer  are  various  other  spreadsheet  and  word 
processing  applications  that  may,  at  times,  contain  documents 
or  files  at  various  levels  of  classifications  ranging  from 
UNCLASSIFIED  to  SECRET.  The  intention  of  this  section  is  to 
expose  any  possible  database  and  microcomputer  security  risks 
and  prescribe  recommendations  to  solve  the  problems  at  hand. 

Physical  access  to  the  microcomputers  in  the  Readiness  and 
Training  Plans  Department  are  limited  only  by  the  access  to 


the  building  which  it  occupies.  However,  uniformed  and 
civilian  personnel  unfamiliar  to  the  airwing  staff  and 
employees  are  challenged  upon  entering  any  office  or  work 
space.  The  building  is  manned  twenty- four  hours  a  day  and 
access  is  restricted  during  off-duty  hours.  While  the  access 
to  hardware  and  equipment  appears  difficult  for  intruders, 
many  instances  of  theft,  destruction  or  tampering  often 
involve  personnel  familiar  to  the  command.  For  this  reason, 
averting  the  physical  access  risks  must  not  be  ignored. 

A  survey  of  the  current  situation  would  show  that  few 
physical  security  measures  are  in  place.  During  off-duty 
hours  the  micro- computers  in  the  department  are  particularly 
vulnerable  to  intrusion  and  theft.  The  introduction  of  a  risk 
counter-measures  program  should  begin  with  acknowledgement 
that  nothing  in  the  department  is  safe  until  it  is  secured. 
The  first  step  of  the  risk  counter-measures  plan  should  be  to 
physically  secure  all  hardware  and  peripheral  equipment  to 
something  either  stationary  or  requiring  great  difficulty  to 
move.  For  instance,  the  monitors  can  be  secured  with  locking 
stranded  cables  to  the  computer  case,  the  desk  or  a  wall 
fitted  with  a  cable  locking  device.  This  will  significantly 
reduce  the  threat  of  theft  in  the  department. 

The  second  step  of  reducing  physical  risk  involves  access 
to  the  operating  system  and  applications  contained  on  the 
computer.  Password  protection  is  a  necessary  element  of  any 
file  management  or  program  application  when  it  involves 
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classified  data.  The  current  operating  system,  DOS  ver.  5.0, 
allows  for  the  use  of  password  protected  files,  however  it 
cannot  prevent  the  use  and  manipulation  of  the  operating 
system.  Other  applications  found  on  the  computers  in  the 
department  all  possess  some  sort  of  password  protection  for 
their  filet.  Paradox  can  password  protect  the  taties  that 
contain  the  data  and  ZTRAX  can  prevent  access  to  the 
application  by  preventing  data  entry  or  edit  without  a  proper 
password. 

It  is  obvious  there  is  a  problem  with  so  many  password 
protected  files  and  applications.  How  many  files  should  you 
protect?  To  correctly,  i.e.,  change  passwords  every  90  days, 
maintain  a  system  with  this  many  required  passwords  woui’.d  be 
a  huge  undertaking  and  administrative  nightmare.  It  is 
therefore  recommended  that  a  security  software  package  be 
purchased  for  the  existing  system.  Most  microcomputer 
security  software  can  provide  the  same  functionality  as 
passwords  can  with  the  benefit  of  only  one  password  per  user. 
A  security  system  of  this  sort  also  provides  many  benefits 
beyond  multi-level  access  protection.  Reports  of  user  log-on 
and  log-off  times  and  discrete  audit  trails  are  two  major 


benefits . 

Perhaps 

the  greatest 

benefit  is  the 

sole 

responsibility  for 

appropriate 

access  to  files 

and 

applications 

rests  wi 

the  system 

administrator (SA) . 

In 

reality,  access  responsibility  is  already  a  function  of  the 
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SA,  in  this  case  the  department  head,  but  now  access  to  the 
system  is  steadfast  and  controllable. 

The  third  step  of  any  security  program  is  data  protection. 
This  is  a  twofold  problem.  First,  data  on  the  computer  must 
be  protected,  and  second,  backup  data  on  floppy  disk  must  be 
protected.  The  relative  risks  in  this  department  situation 
involve  data  stored  on  the  computer.  Backup  disks  are  all 
secured  in  a  combination  locked  filing  cabinet  which  is 
accessible  only  by  the  department  head.  Several  software 
applications  provide  functions  which  prohibit  the  editing  of 
data  without  proper  access  or  display  warnings  explaining  the 
consequences  of  such  edits.  A  software  security  package  can 
also  provide  some  measures  of  control  in  regards  to  data  edits 
by  restricting  users  to  certain  functions  of  file  and  database 
operations  that  can  prevent  unauthorized  edits  from  occurring. 
Another  function  of  security  software  is  the  encryption  o'" 
data  fil ?s.  This  is  an  enormous  benefit  to  the  security  of 
the  data  because  if  a  user  or  intruder  was  somehow  able  to  get 
through  the  password  protection  and  into  the  file  manager  of 
the  operating  system  the  files  would  all  be  encrypted  and  thus 
useless  as  a  source  of  information. 

The  above  illustrate  several  elements  of  risk  found  in  the 
Readiness  and  Training  Plans  department.  These  risks  occur  in 
a  wide  range  of  commands  within  the  Navy  and  must  be 
recognized  in  order  to  be  dealt  with  in  an  appropriate  manner. 
Aside  from  physically  restraining  hardware  and  peripherals. 
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the  single  most  effective  security  measure  available  is  the 
institution  of  a  microcomputer  security  software  application 
which  provides  password  protection,  audit  trails,  file 
management  tools  and  data  encryption  capability. 

D .  RECOMMENDATIONS 

Safeguarding  non- complex  microcomputer  environments 
involves  a  variety  of  measures  which  can  be  easily  initiated 
and  maintained.  The  first  step  is  completing  a  security 
survey  and  risk  analysis  profile  of  the  organization. 
Available  from  the  NAVTELCOMSTA  Jacksonville,  Florida  is  the 
"Microcomputer  Security  Survey  and  Microcomputer  Baseline 
Security  Controls  Risk  Analysis  Alternative".  This  document 
is  a  tool  to  gather  various  system  information  and  address  any 
risk  associated  with  the  current  operating  environment. 
Divided  into  two  parts,  part  one  is  a  survey  form  which 
gathers  the  necessary  system  information.  Part  two  describes 
the  "baseline  approach"  used  to  identify  and  manage  associated 
risks.  Upon  completion  of  the  survey,  several  controls  may  be 
recommended  to  minimize,  counter  or  prevent  the  threat  of 
accidents,  human  errors,  physical  and  environmental  controls 
(NAVCOMTELSTA,  1991) . 

1.  Safeguarding  Data 

Implementing  data  protection  safeguards  are  an 
essential  element  of  a  total  security  plan.  Administrative 
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items,  such  as  periodically  reviewing  the  list  of  authorized 
users,  the  microcomputers  and  applications  they  are  cleared  on 
and  changing  passwords  regularly  can  prevent  data  loss. 
Several  software  vendors  offer  a  variety  of  inexpensive 
programs  which  can  provide  password  protection  and  encryption 
for  files,  audit  trails  and  operating  system  level  data  and 
access  controls.  Several  other  suggestions  are  obvious  but 
often  ignored.  Keeping  unneeded  sensitive  data  off  the 
machines  and  disguising  the  netmes  of  those  files  that  are 
present  lessens  the  possibility  of  an  incident  or  accident. 
Encryption  and  periodic  purge  of  outdated  files  is  another 
method  providing  good  security.  Access  controls  for  software 
applications  provide  an  outstanding  means  to  not  only  deter 
intruders  but  can  also  provide  audit  trails  of  attempted 
unauthorized  access.  While  all  methods  are  not  appropriate 
for  all  operating  environments  it  is  essential  that  some  sort 
of  data  controls  be  implemented  (NCTAMS  LANT,  1991) . 

2 .  Physical  Access  Protection 

Physical  access  protection  means  providing  a  secure 
area  in  which  to  operate  and  store  microcomputer  devices,  data 
and  peripheral  equipment .  Securing  an  area  through  the  use  of 
combination  cipher  locks  on  doors  or  by  restricting  access  to 
certain  areas  of  the  building  are  reliable  methods  of  access 
denial .  Equipment  safeguards  such  as  a  lock  down  apparatus 
and  power  switch  protectors  can  also  deter  intruders  from 
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gaining  any  valuable  material  from  the  work  space.  Physical 
access  protection  is  the  most  visible  and  overt  deterrent  to 
attempted  security  ministrations.  They  should  be  implemented 
in  all  microcomputer  environments  (NCTAMS  LANT,  1991) . 

In  this  information  age  of  escalating  computer  fraud 
and  theft,  system  integrity  and  security  should  not  be 
sacrificed  for  any  reason.  Inexpensive,  reliable  software 
protection  is  readily  available  from  a  multitude  of  vendors. 
Several  DOD,  SECNAV  and  OPNAV  instructions  relating  to  the 
operational  security  of  AIS  elements  prove  it  is  an  issue 
worthy  of  vital  concern. 
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V.  CONCLUSIONS  and  RECOMMENDATIONS 

The  installation  and  use  of  the  ZTRAX  relational  database 
tracking  system  has  made  a  significant  positive  impact  on  the 
daily  operations  of  the  Readiness  and  Training  Plans 
Department  since  its  inception  in  November  1991.  The  ability 
to  query  information  through  the  use  of  an  RDBMS,  vice  the 
previous  method  of  manually  researching  and  preparing  data,  is 
providing  the  users  a  greater  understanding  of  training  and 
readiness  trends  for  individual  squadrons  and  the  entire 
organization.  Information  such  as  this  will  lead  to  the 
eventual  development  of  optimal  training  and  deployment  cycles 
for  operational  squadrons  and  airwings. 

ZTRAX  is  providing  a  vast  array  of  information  which  was 
previously  difficult  to  obtain.  However,  there  are  several 
drawbacks  to  using  the  department's  Z-248  microcomputers.  The 
first  and  most  noticeable  is  the  speed  at  which  the  processor 
operates.  Benchmark  times  of  an  80206  processor  running  at 
8MHz  for  single  queries  exceed  1  minute  and  multiple  queries 
exceed  l  minute  45  seconds  as  compared  to  an  80386  running  at 
20  MHZ  which  was  below  20  seconds  for  single  queries  and  below 
30  seconds  for  multiple  queries.  Several  factors  contribute 
to  the  query  benchmarks  shown  above.  The  80286  chip  is  by  no 
means  state  of  the  art  and  the  majority  of  todays  leading  edge 
software  applications,  such  as  Paradox,  are  designed  to  run  on 
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faster  machines.  The  RAM  available  on  a  Z-284  is  640Kb. 
Because  ZTRAX  is  most  effectively  run  through  Paradox  to 
utilize  many  of  its  local  functions,  the  program  has  to 
continually  access  the  hard  disk  for  data.  This  hard  disk  is 
currently  95  percent  filled  with  various  records  of  historical 
flight  hour  and  readiness  data  not  related  to  ZTRAX  or 
Paradox,  thereby  making  access  times  extremely  slow. 

There  are  three  alternatives  to  this  situation: 


1.  Maintain  the  status  quo.  This  alternative  is  not 
recommended  based  on  the  expected  growth  of  the  use  of  the 
ZTRAX  application  and  the  current  idle  time  experienced  by 
users  waiting  for  query  results  and  report  displays. 

2.  Upgrade  the  existing  system  with  a  new  processor,  hard 
disk  and  expanded  RAM.  GSA  Companion  Contract  N66032-91-D- 
002  provides  for  Z-248  upgrades  that  are  offered  by  Zenith. 
The  cost  of  an  upgrade  to  an  80386DX  processor  running  at 
25MHz  with  4  megabytes  of  RAM  on  the  motherboard  and  a  44 
megabyte  hard  disk  is  $1663,  plus  labor  to  install.  This 
alternative  is  not  recommended  because  this  option  is 
essentially  replacing  70  percent  of  the  component  parts  of 
a  Z-248  for  80  percent  of  the  cost  of  a  completely  new 
system.  The  departments  Z-248 's  have  been  in  operation  over 
six  years  and  the  parts  that  are  replaced  with  this  upgrade 
must  be  considered  for  replacement  in  the  near  future. 

3.  The  purchase  of  a  new  80386  machine  with  a  168  megabyte 
hard  disk,  4  megabytes  of  RAM,  VGA  monitor  and  associated 
software  and  components  per  the  current  GSA  Desktop  III 
contract,  number  F01620-90-D-0001.  This  system  not  only 
solves  existing  problems  with  processor  speeds  and  hard  disk 
capacity  but  will  meet  the  future  needs  of  establishing  a 
Decision  Support  System  with  the  ZTRAX  database  tables. 
This  desktop  model,  SLIN  0034AB,  is  priced  at  $2103. 
Considering  the  anticipated  problems  with  extending  the 
useful  life  through  upgrades  of  the  Z-284 's,  this  is  the 
most  viable  solution. 


The  purchase  of  two  new  microcomputers  for  the  department 
will  significantly  increase  the  speed  and  quality  of  output. 
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Although  the  new  machines  will  not  affect  input  methods  for 
data  entry,  the  eibility  to  install  the  complete  Paradox 
program  on  the  hard  disk  will  enadDle  the  use  of  the  FLIMPORT 
utility.  This  utility  imports  data  from  fixed-length  ASCII 
formatted  files  into  the  ZTRAX  database  tables  through  a  named 
specification  file.  If  the  ability  to  receive  the  monthly 
Training  and  Readiness  and  Flight  Hour  messages  from  the  local 
communications  center  on  floppy  disk  in  the  required  ASCII 
format  were  present,  FLIMPORT  would  eliminate  all  the  time 
currently  required  for  data  entry. 

The  success  of  ZTRAX  operations  within  the  department  is 
overshadowed  by  the  lack  of  security  for  the  integrity  of  the 
database  program,  its  data  and  the  data  of  associated  applica¬ 
tions  contained  on  the  same  microcomputer.  Both  machines  in 
the  department  have  been  TEMPOS  approved  for  classified 
information,  yet  neither  use  any  of  the  available  security 
measures  recommended  in  Chapter  IV.  WATCHDOG  Version  6.0  is 
a  security  system  that  provides  access  control,  data  and  file 
protection,  transparent  data  encryption,  virus  protection, 
audit  trail  facilities,  system  administration  and  a  fixed  disk 
management  system.  All  of  these  features  are  necessary  com¬ 
ponents  of  a  thorough  and  complete  microcomputer  security 
system  which  will  help  to  guarantee  system  integrity.  This 
software  is  available  under  GSA  contract  number  GS00K91AGS5038 
from  Government  Technology  Services,  Inc.  under  GTSI  Part 
Number  298-001-019. 
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This  thesis  has  presented  the  functional  requirements, 
design  and  implementation  of  ZTRAX:  an  RDBMS  for  tracking  and 
evaluating  squadron  training,  readiness  and  flight  hour  data. 
An  evaluation  of  the  existing  information  system  and  its 
ability  to  fully  utilize  the  functions  of  ZTRAX  and  Paradox 
was  also  discussed.  Recommendations  were  made  as  to  the  most 
beneficial  steps  to  take  to  ensure  the  maximum  capabilities  of 
the  RDBMS  are  met  and  the  integrity  of  the  data  remains 
secure.  The  need  for  this  application  is  the  requirement  for 
the  maximum  utilization  of  training  combat  ready  aircrews  in 
an  era  of  diminishing  appropriated  funding  for  that  purpose. 
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APPENDIX  A.  SOURCE  DOCUMENTS 


COMPATWINGS  PAC INSTR  3500.1 

SAMPLE  MONTHLY  TRAINING  AND  READINESS  REPORT  MESSAGE 
EXAMPLE  -  CLASSIFICATION  MARKS  ARE  FOR  FORMAT  ONLY 
FM:  PATRON  XX 

TO:  COMNAVAIRPAC  SAN  DIEGO  CA//3121// 

INFO:  COMPATWINGS PAC  MOFFETT  FIELD  CA//50// 

COMPATWING  XXX//50// 

CONFIDENTIAL  //N03500// 

SUBJ:  MONTHLY  TRAINING  AND  READINESS  REPORT  (U) 


1. 

(C) 

A.  PATRON  XX 

B.  MARCH 

:  90 

C.  N/A 

2  . 

(C) 

A.  33 

B. 

1 

C. 

1 

D.  29/3/1 

E,  24 

F. 

0 

G. 

1 

H.  21/2/1 

I.  75 

J. 

3 

K. 

2 

3  . 

(C) 

A. 

B. 

C. 

D. 

ASU 

C-3 

7 

64 

ASW 

C-1 

11 

100 

CCC 

C-1 

10 

90 

ELW 

C-1 

11 

100 

INT 

C-1 

11 

100 

LOG 

C-1 

11 

100 

MIW 

C-4 

4 

36 

MOB 

C-1 

10 

90 

FHR 

C-3 

34 

68 

4  . 

(C) 

70.2/19 

5  . 

(C) 

A.  1.  23 

.0  2. 

98.6 

3. 

30.0  4 

.  16.0 

5.  167.6 

6.  0 

B.  1.  121.0  2. 

0 

3. 

35.4  4 

.  29.0 

5.  185.4 

6.  0 

6  . 

(C) 

A.  ICEX 

90 

A2  . 

PACEX 

90 

B.  8-17 

MAR  90 

B2. 

20-25 

MAR  90 

C.  40.2 

C2. 

20.5 

7. 

(U) 

N/A 

8. 

(C) 

6  DAYS 

MIDWAY  ISLAND 

1-6 

MAR 

90 

PONY 

EXPRESS 

9. 

(U) 

N/A 

10, 

.  (C) 

1.  SQUADRON  SCHEDULED 

FOR  MRCI  IN  APRIL. 

EXPECT  C-2 

IN 

MIW 

FOLLOWING 

MRCI. 

2.  4  CREWS  NOT  OP  READY  IN  ASU  AWAITING  REQUAL  (A- 39) 
OPPORTUNITY  WITH  BG  FOXTROT  ON  APR  9. 

3.  FLIGHT  HOURS  LOW  DUE  TO  POST  DEPLOYMENT  LEAVE. 

THIS  PAGE  UNCLASSIFIED 
CLASSIFICATION  MARKS  ARE  FOR  FORMAT  ONLY 

End  (3) 


43 


CONFIDENTIAL  when  filled  in 
COMPATWINGS PACINST  3  5  0  0 . 2  7A 

FM:  PATRON  XXX 

TO:  COMPATWINGS PAC  MOFFETT  FIELD  CA/ /5l/ / 

INFO:  COMASWFORPAC  PEARL  HARBOR  HI//ASW3// 

COMPATWING  TEN  MOFFETT  FIELD  CA//30// 

COMPATWING  TWO  BARBERS  POINT  HI//30// 

COMPATWING  ONE  KAMI  SEYA  JA//30// 
CONFIDENTIAL  //N03500// 

SUBJ:  MONTHLY  FLIGHT  HOUR  REPORT  FOR  MONTH/YEAR  (U) 

REF/A/ COMPATWINGSPACINST  3500.27A/1  AUG  91// 

1.  IN  ACCORDANCE  WITH  REF  A,  THE  FOLLOWING  REPORT  IS 
SUBMITTED : 

H 

/  # 

D  SOR  ONSTA  TOTAL  CONT 

I.  TASKED  OPERATIONAL  HRS 

A.  INDEP  ASW 

( 1 )  Type  _  _  _  _  _ 

B.  COORD  ASW 

( 1 )  Type  _  _  _  _  _ 

C.  COMBINED  ASW 

{ 1 )  Type  _  _  _  _  _ 

D.  INDEP  INT/SUR  _  _  _  _  _ 

E.  COORD  INT/SUR  _  _  _  _  _ 

F.  COMBINED  INT/SUR  _  _  _  _  _ 

G.  CCC  _  _  _  _  _ 

H.  COMBINED  CCC  _  _  _  _  _ 

I.  ELW  _  _  _  _  _ 

CONFIDENTIAL  when  filled  in 
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CONFIDENTIAL  when  filled  in 
COMPATWINGSPACINST  3 5 0 0 . 2 7A 


PATROL  SQUADRON  FLIGHT  HOUR  REPORT  CON'T 


H 

/ 

D 


# 

SOR  ONSTA  TOTAL  CONT 


J.  COORD  ELW  _ 

K.  COMBINED  ELW  _ 

L.  ASU  _ 

M.  COORD  ASU  _ 

N.  COMBINED  ASU  _ 

O.  DEPL.  TRANSIT  _ D_ 

P.  DET  TRANSIT  _ 

Q.  PONY  EXPRESS  _ 

R.  LOGISTICS  SUPPORT 

(1)  Specify  _ 

S.  OTHER 

(1)  Specify  _ 

T.  TOTAL  CONTINGENCY  _ 

U.  TOTAL  OPERATIONAL  _ 

II.  INDEPENDENT  TRAINING  HOURS 
A.  ASW 

( 1 )  CAST  _ 

(2)  A-37  _ 

(3)  NIB  _ 

(4)  OTHER 

(A)  Specify  _ 

(5)  TOTAL  INDEP  ASW  _ 


CONFIDENTIAL  when  filled  in 
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CONFIDENTIAL  when  filled  in 
COMPATWINGS PACINST  3  5  0  0 . 2  7A 


PATROL  SQUADRON  FLIGHT  HOUR  REPORT  CON*T 

H 

/  # 

D  SOR  ONSTA  TOTAL 

B.  INT/SUR 

(1)  A-30  _  _  _  _ 

(2)  OTHER 

(A)  Specify  _  _  _  _ 

(3)  TOTAL  INT/SUR  _  _  _  _ 

C.  MIW 

(1)  A-38  _  _  _  _ 

(2)  MRCI/WKUP  _  _  _  _ 

( 3 )  OTHER 

(A)  Specify  _  _  _  _ 

(4)  TOTAL  MIW  _  _  _  _ 

D.  ELW 

(1)  Specify  _  _  _  _ 

E.  ASU 

(1)  Specify  _  _  _  _ 

F.  BOMBEX 

(1)  Specify  _  _  _  _ 

G.  TOTAL  INDEP  TRNG  _  _  _  _ 

III.  PILOT/CREW  TRAINING  HOURS 

A.  PILOT  TRNG 

(1)  SYLLABUS  _  _  _ 

(2)  PPT  _  _  _ 

( 3 )  INSTRUMENT  _  _  _ 

(4)  AIRWAYS  _  _  _ 

(5)  NATOPS  _  _  _ 

CONFIDENTIAL  when  filled  in 
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CONFIDENTIAL  when  fiT*  -.i  in 
COMPATWINGS PACI-"’':  V  3  b  0  0 . 2  7A 


PATROL  SQUADRON  FLIGHT  HOUR  REPORT  CON- T 


H 

/  # 

D  SOR  ONSTA  TOTAL 

(6)  TOTAL  PILOT  TRNG  _  _  _ 

B.  CREW  TRNG 

( 1 )  SYLLABUS  _  _  _ 

(2)  OVR  WTR  NAV  _  _  _ 

(3)  NATOPS  _  _  _ 

(4)  TOTAL  CREW  TRNG  _  _  _ 

C.  TOTAL  P/C  TRNG  _  _  _ 

IV.  MISCELLANEOUS  TRAINING  HOURS 

A.  MAINT  CHECK  _  _  _ 

B.  MAD  COMP  _  _  _ 

C.  WST  TRANS  _  _  _ 

D.  SCHOOL  FLTS  _  _  _ 

E .  FERRY  _  _  _ 

F.  OTHER 

(1)  Specify  _  _  _  _ 

G.  TOTAL  MISC  _  _  _  _ 

V.  TOTAL  TRAINING  _  _  _  _ 

VI.  COORDINATED/COMBINED  EXERCISE  HOURS 

A.  COORD  ASW 

(1)  Specify  _  _  _  _ 

B.  COORD  INT/SUR  _  _  _  _ 

(1)  Specify 

CONFIDENTIAL  when  filled  in 


CONFIDENTIAL  when  filled  in 
COMPATWINGSPACINST  3  5  0  0 . 2  7A 

PATROL  SQUADRON  FLIGHT  HOUR  REPORT  CON'T 


/  # 

D  SOR  ONSTA  TOTAL 


C.  CCC 

(1)  Specify 

D.  COORD  ASU 
(1)  Specify 

E.  COORD  MIW 
(1)  Specify 

F.  TOTAL  COORD  EXERCISE 


G.  COMBINED  ASW 
(1)  Specify 

H.  COMBINED  INT/SUR 
(1)  Specify 

I.  COMBINED  CCC 
(1)  Specify 

J.  COMBINED  ASU 
(1)  Specify 

K.  COMBINED  MIW 
(1)  Specify 

L.  TOTAL  COMBINED  EXER 


M.  TOTAL  EXERCISE  HOURS 


VII.  SERVICE  HOURS 
A.  C/N 


B.  ACFT  SVCS 


(1) 

Specify 

C.  SAR 

D.  CNO 

PROJECTS 

(1) 

Proj  # 

CONFIDENTIAL  when  filled  in 
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CONFIDENTIAL  when  filled  in 
COMPATWINGS PACINST  3  5  0  0 . 2  7A 


PATROL  SQUADRON  FLIGHT  HOUR  REPORT  CQN'T 

H 

/  # 

D  SOR  ONSTA  TOTAL 

E.  TAC  D&E 

(1)  Proj  name  _  _  _  _ 

F.  RECRUITING  _  _  _  _ 

G.  STATIC  DISP  _  _  _  _ 

H.  ORIENT/DEMO  _  _  _  _ 

I.  STAFF  SUPPORT  _  _  _  _ 

J.  OTHER 

(1)  Specify  _  _  _  _ 

K.  TOTAL  TASKED  SERVICES  _  _  _  _ 

'''III.  TOTALS 

A.  TOTAL  MONTHLY  HRS  ^H_  _  _  _ 

B.  TOTAL  MONTHLY  HRS  ^D_  _  _  _ 

C.  TOTAL  HOURS  _H/D  _  _  _ 

IX.  MONTHLY  PILOT  ANALYSIS 

A.  MONTHLY  AVERAGE  1ST  TOUR,  1ST  PILOT  TIME:  _ 

B.  NUMBER  OF  1ST  TOUR  PILOTS  NOT  ACQUIRING  10  HOURS  OF  1ST 

PILOT  TIME:  _ 

C.  NUMBER  OF  1ST  TOUR  PILOTS  BEHIND  IN  PEF:  _ 

D.  IP  STATUS 

RANK  MONTH/ YR  DESIG  PRD 


CONFIDENTIAL  when  filled  in 
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CONFIDENTIAL  when  filled  in 
COMPATWINGSPACINST  3  5 0  0 . 2  7A 

PATROL  SQUADRON  FLIGHT  HOUR  REPORT  CON*T 

X,  MONTHLY  DETACHMENT  OPERATIONS 

SITE  #ACFT  SCREWS  ftPAYS  OPS  TRNG  EXER  SVCS  PILOT/CREW 

HRS  HRS  HRS  HRS  POSITIONING 


1) 


CONFIDENTIAL  when  filled  in 
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APPENDIX  B.  OBJECT  DIAGRAMS 


jp _ 

MANNING 

jR-LEVELS 
I NIGHTHRS 
I  FLT  HOURS  i 

j  DETOPS  i 


MV 

MV 

MV 

MV 


RDYRPT  Ol^ect 


SQUADRON 

MONTH 

YEAR 

REPORT 

STATUS 

MV 

ID  Object 


i|D _ 

RANK 

MV 

DESIGNATION 

RPD 


INST  PILOTS  ObKst 


ID 

FLTHRS 
PILOT  STATS 
INST  PILOTS 
DETOPS 


MV 

MV 

MV 


FLTRPT  Object 


]p _ 

POSITION 

1 

TOTAL 
GAINS 
LOSSES 
CAT  I 
CAT  II 
CAT  III 


MANNING  Object 


fiD 

I _ 

NIGHT  HOURS 
%  OF  TOTAL 


NIGHTHRS  Object 


IP _ 

PMA  NAME 

MV 

C-RATING 

CREWS 

PERCENTAGE 


R-LEVELS  Object 


IP _ 

CATEGORY 

AP-2A 

TYPE 

SPECIFIC  TYPE 
MATRIX 

FLT  HOURS  Object 


i  'ID 

i - 

DETTYPE 

DET  NAME 
i  DATE 

I 

TOTAL  HRS 

j  #AIRCRAFT  I 

i  I 

#CREWS  ! 

I  I 

i  #DAYS 

I 

t  SITE 

Iflthrs  i 

i - MV  I 

:  ] 

DETOPS  Object 


IP _ 

1ST  PILOT  TIME 
DERCIENT  PILOTS 
PEF  PILOTS 


PILOT  STATS  Object 


SORTIES 

ONSTATION 

TOTAL 

CONTINGENCY 

FLTHRS 

MATRIX  Object 
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APPENDIX  C. 


OBJECT  DEFINITIONS 


DETQPS  OBJECT 

ID;  ID  Object 
Det  Type;  Det_Type 
Det  Name ;  Det_Name 
Date;  Date 
Total  Hrs;  Hrs 
#Acft;  Acft 
# Crews ;  Crews 
#Days ;  Days 
Site;  Site 

FLTHRS;  FLTHRS  Object;  MV;  SUBSET [Category] 


FLTHRS  OBJECT 

ID;  ID  Object 

Category;  Category_Name 

Area ;  Area_Name 

Type ;  Type_Name 

Specific  Type;  Specif ic_Name 

MATRIX;  MATRIX  Object 


FLTRPT  OBJECT 


ID;  ID  Object 

FLTHRS;  FLTHRS  Object; MV 

PILOT  STATS;  PILOT  STATS  Object; 

INST  PILOTS;  INST  PILOTS  Object;  MV 

DETOPS;  DETOPS  Object;  MV 


ID  OBJECT 


Squadron;  Squadron_Nuinber 
Month;  Month 
Year;  Year 

Report ;  Report_Type ;  MV 
Status;  Squadron_Status ;  MV 
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INST  PILOT  OBJECT 

ID;  ID  Object 
Rank ;  Rank ;  MV 
Desig;  Date 
PRD;  Date 


MANNING  OBJECT 
ID;  ID  Object 

Position;  Position_Naine ;  MV 
Total;  Position_Total 
Gains;  Position_Gains 
Losses;  Position_Losses 
Cat  I;  Cat  I 
Cat  II;  Cat  II 
Cat  III;  Cat  III 


MATRIX  OBJECT 

FLTHRS;  FLTHRS  Object 
Sorties;  Sorties 
Onstation;  Onsta 
Total ;  Hrs 
Contingency;  Cont 


NIGHTHRS  OBJECT 

ID;  ID  Object 
Night  Hours;  Hrs 
%  of  Total;  Percent 


PILOT  STATS  OBJECT 

ID;  ID  Object 
1st  Pilot  Time;  IPT 
Deficient  Pilots;  DPT 
PEF  Pilots;  PEF 
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RDYRPT  OBJECT 

ID;  ID  Object;  SUBSET [Squadron,  Month,  Year,  Report] 

MANNING;  MANNING  Object;  MV 

R- LEVELS;  R- LEVELS  Object;  MV 

NIGHTHRS;  NIGHTHRS  Object 

FLTHRS;  FLTHRS  Object;  MV 

DETOPS;  DETOPS  Object;  MV 


R- LEVELS  OBJECT 


ID;  ID  Object 
PMA;  PMA_Naine;  MV 
C- rating;  C- rating 
Crews ;  Crews 
Percentage;  Percent 
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APPENDIX  D. 


DOMAIN  DEFINITIONS 


IPT: 

Numeric  999.9 

Average  number  of  lat  pilot  time  flight  hours  for  report 
month 

Acf  t : 

Nvimeric  99 

Niimber  of  individual  aircraft  at  a  detachment  site 

Area_Name : 

Text  2  5 

Indicates  second- level  categorization  of  flight  hours 

CAT  I: 

Numeric  99 

Number  of  Category  I  Officers  in  a  squadron  during  report 
month 

CAT  II; 

Numeric  99 

Number  of  Category  II  Officers  in  a  squadron  during  report 
month 

CAT  III: 

Numeric  9 

Number  of  Category  III  Officers  in  a  squadron  during  report 
month 

Category_Name : 

Text  25 

Indicates  first- level  categorization  of  flight  hours 
Cont : 

Numeric  99 

Number  of  contingency  events  for  a  specific  category 

C- rating : 

Numeric  N 

Rating  factor  of  1  to  4  assigned  to  a  Primary  Mission  Area 

Crews : 

Numeric  99 

Specific  number  of  individual  crews 
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Date : 

Text  6,  Mask  MMM  YY, 

where  MMM  is  the  three  letter  abbreviation  for  any 
month,  YY  is  the  last  two  digits  of  any  year 
Indicates  a  month/yr  combination 

Days : 

Numeric  999 

Specific  number  of  days  at  a  detachment  site 

Det_Name : 

Text  25 

Name  of  an  operation,  perstempo,  exercise  or  contingency 
detachment 

Det_Type; 

Text  25 

Categorizes  detachments  as  one  of  the  following (Exercise, 
Contingency  or  Perstempo) 


DPT 

Numeric  99 

Numeric  measure  of  the  number  of  pilots  in  a  squadron  not 
acquiring  10  hours  of  first  pilot  time  during  the  reporting 
month 

Hrs ; 

Numeric  9999.9 

Indicates  total  nximber  of  flight  hours  for  a  specific 
category  for  report  month 

Month : 

Text  3 

Three  letter  abbreviation  for  any  month 
Onsta : 

Numeric  999.9 

Number  of  flight  hours  onstation  associated  with  one  or  a 
series  of  related  events 

PEF: 

Numeric  99 

Numeric  measure  of  the  number  of  first  tour  pilots  behind 
in  PEF  for  the  reporting  month 

Percent : 

Numeric  99 

Percentage  ratio  of  one  event  or  category  to  another 
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PMA_Naine : 

Text  3 

Specifies  Primary  Mission  Area(PMA)  for  R- Levels  object 

Position_gains : 

Numeric  99 

Identifies  total  number  of  entity  gains  for  a  given 
position 

Position_losses : 

Numeric  99 

Identifies  total  number  of  entity  losses  for  a  given 
position 

Pos i t i on_Name : 

Text  7 

Describes  position  for  Manning  information (limited  to 
Pilots,  Nfos  or  Aircrew) 

Position_total : 

Numeric  99 

Identifies  total  number  of  entities  for  a  given  position 

Rank: 

Text  4 

Abbreviation  for  Officer  rank  in  U.S.  Naval  Seirvice 

Report_Type : 

Text  3 

Identifies  type  of  report  where  data  originated (limited  to 
TRR-Training  and  Readiness  Report  and  FHR- Flight  Hour 
Report) 


Site : 

Text  25 

Names  for  detachment  locations 

Sorties : 

Numeric  999 

Number  of  sorties  involved  with  a  specific  event  or  series 
of  related  events 

Spe  c i f i c_Name : 

Text  15 

Indicates  fourth- level  categorization  of  flight  hours 

Squadron_number : 

Numeric  99 

Numeric  identifier  for  a  Patrol  Squadron 
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Squadron_status : 

Text  8 

Identifies  Home  or  Deployed  status  of  squadron  during 
report  month 

Type_name : 

Text  10 

Indicates  third- level  categorization  of  flight  hours 

Year: 

Numeric  2 

Identifies  any  year  by  the  last  two  digits 
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I .  INTRODUCTION 

ZTRAX  is  a  readiness  and  flight  hour  relational  database 
management  system  designed  to  store  squadron  training,  readiness 
and  flight  hour  data  from  monthly  reports  and  provide  information 
in  graphic  or  tabular  form.  Specific  data  and  information  are 
retrie\'ed  using  PARADOX  query  by  example  (QBE)  techniques.  A 
working  knowledge,  i.e  completing  the  Paradox  tutorial  which 
accompanies  the  program,  of  Paradox  functions  is  required  to  fully 
utilize  this  application.  ZTRAX  is  run  through  PARADOX  by: 

1.  Selecting  the  Script  option  of  the  PARADOX  main  menu 


View  Ask  Report  Create  Modify  Image  Forms  Tools  Scripts  Play  or 
PARADOX  Main  Menu 


2.  Selecting  the  Play  option  from  the  Scripts  menu 


Play  Begin  Query  Show  Repeat  Editor 

Record  Save  Play  Play 

Play  a  script. _ 

PARADOX  Scripts  Menu 


3.  Entering  "ZTRAX"  at  the  Script  prompt. 


Script:  ZTRAX 

^Enternam^ofsc^ptt^p^^ 

PARADOX  Scripts/Play  Menu 

Upon  program  execution  the  "ZTRAX"  main  menu  will  appear  at  the 
top  of  the  screen.  Selection  of  all  menu  items  in  ZTRAX  is 
accomplished  by  using  the  left/right  arrow  keys  to  highlight  the 
selection  and  the  enter/return  key  to  select  the  menu  item.  The 
escape  key  may  be  used  at  any  time  to  move  up  one  menu  level. 
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Readiness  Pit  Hrs  Leave 
ZTRAX  Main  Menu 

An  essential  note;  after  all  database  operations  remember  to 
save  the  updated  ZTRAX  tables  to  a  backup  floppy  disk.  This  will 
insure  data  integrity  in  case  of  system  crash.  The  backup 
procedure  is  simple.  First,  because  ZTRAX  automatically  saves  the 
new/updated  data  to  the  tables  on  the  hard  drive  you  must  only  save 
that  data  for  a  backup  copy.  After  exiting  ZTRAX  you  remain  in  the 
main  Paradox  program  with  the  main  menu  displayed  on  the  screen. 
From  here: 

1.  Select  Tools  from  the  main  menu. 


View  Ask  Report  Create  Modify  Image  Forms  TOOLS  Scripts  Exit 
PARADOX  Main  Menu 


2.  Select  Copy  from  the  Tools  menu. 


Rename  QuerrySpeed  Exportimport  Copy  Delete  Info 
Mak^a^^og^^^^jrab]^e^^ustOTn^omn^^egor|^^^^cr^g^ 

TOOLS  Menu 


3.  Select  Table  from  the  Copy  menu. 


Table  Form  Report  Script  JustFamily  Graph 
^Cop^^^ab^^an^^^^fam^^^^fonn^^^port^an^^idex^ 

Table  Menu 
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4.  At  the  Table  prompt  select  the  table  to  copy,  in  this  example 
we  will  use  the  FLTHRS  table. 


Table:  FLTHRS 

^Ente^nam^o^tab^^t^copj^o^<RETUMJ^t^se^^^^s^^^^^^^^ 
PARADOX  Tools /Table  Menu 

5.  After  you  enter  the  table  name  and  press  return  Paradox  will 
request  a  new  name  to  copy  the  table  to.  Because  this  is  a  backup 
copy  we  use  the  same  name  for  the  table  but  specify  a  new  drive  and 
directory.  In  this  case,  we  use  the  A  drive,  ZTRAX  subdirectory 
and  the  FLTHRS  table  name. 


Table:  A:\ZTRAX\FLTHRS 
PARADOX  Tools/Table  Menu 

Backup  copies  of  tables  and  data  are  a  standard  procedure  for 
all  database  operations,  regardless  of  their  size  or  scope.  It  is 
a  safeguard  against  processor  or  hard  disk  failure  and  is  most 
highly  recommended  for  use  with  ZTRAX. 
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II.  ADDING  NEW  DATA 

There  are  two  distinct  ways  to  enter  new  data  into  the  tables 
which  comprise  ZTRAX.  The  first,  and  most  efficient,  is  the  use  of 
the  ZTRAX  menu  structure.  The  second,  used  to  accomplish  any  phase 
of  database  operations,  is  the  manipulation  of  the  PARADOX  program. 
This  option  is  not  advised  for  data  entry  and  edit  due  to  the  size 
of  the  tables  and  the  large  number  of  fields  contained  within  them. 

Data  entry  is  accomplished  with  the  keyboard.  Incorrectly 
formatted  fields,  i.e.  putting  an  alphabetic  character  in  a  niimeric 
field,  is  met  with  a  beep  from  the  program  and  a  blinking  cursor  in 
that  particular  field.  The  majority  of  the  data  entry  fields  are 
numeric  and  they  follow  the  format  of  the  source  documents,  the 
Training  and  Readiness  and  Monthly  Flight  Hour  reports.  Therefore, 
if  a  field  is  numeric  on  the  source  document,  it  is  numeric  in  the 
database . 

A.  Readiness  Report 

1.  Selecting  READINESS  from  the  main  ZTRAX  menu  will  display  the 
following  menu: 


ADD  EDIT  VIEW 

ADD  NEW  MONTHLY  READINESS  REPORT  DATA 


Readiness  Main  Menu 


2.  Highlighting  Add,  as  shown  above,  and  pressing  the 
enter/return  key  will  display  a  data  entry  form  duplicating  a 
readiness  message.  This  form  consists  of  three  pages  which  are 
maneuvered  between  by  using  the  page  or  arrow  up/down  keys.  Page 
one  of  the  form  is  the  initial  screen  and  the  blinking  cursor,  to 
the  right  of  SQUADRON,  indicates  the  first  point  of  data  entry 
(Fig. 1)  . 

3.  To  enter  data  just  type  it  as  it  appears  on  the  readiness 
message  into  the  desired  field  and  press  Enter.  ZTRAX  will  advance 
to  the  next  available  field  automatically.  Fields  can  be  skipped 
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by  using  the  arrow  keys  to  select  another  field.  It  is  recommended 
all  fields  be  entered  in  CAPITAL  LETTERS  because  PARADOX  is  case 


sensitive  and  this  will  effect  later  queries. 


MONTHLY  READINESS  REPORT 

1 .  SQUADRON  -  MONTH 

YEAR 

2.  MANNING 

TOTAL  GAINS 

LOSSES 

CATI /CATI I /CATI I I 

PILOTS 

/  / 

NFOS 

/  / 

AIRCREW 

3.  R- LEVELS 

C- RATING 

CREWS 

PERCENTAGE 

ASU 

C- 

ASW 

C- 

CCC 

C- 

ELW 

C- 

INT 

C- 

LOG 

C- 

MIW 

C- 

MOB 

C- 

FHR 

C- 

4.  NIGHT  HOURS  %  OF 

TOTAL 

Figure  1 


4.  After  all  fields  have  been  entered  press  the  [F2]  key  to  save 
the  new  data.  The  [FI]  Help  key  is  the  only  other  operational 
function  key  available  while  using  ZTRAX.  Selecting  [FI]  will 
retrieve  the  standard  PARADOX  Help  Screen. 

5.  In  order  to  create  the  proper  representation  of  a  readiness 
report  for  a  squadron,  it  is  essential  the  three  key  fields; 
Squadron,  Month  and  Year  are  entered  correctly.  If  any  of  these 
fields  are  incorrect,  proper  queries  of  data  will  be  impossible. 
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FLT  HRS  ADD  Menu 


3.  At  this  point,  data  can  be  entered  in  any  one  of  the  five 
displayed  categories.  It  is  recommended  you  follow  the  menu 
sequence  which  is  representative  of  the  FLT  HRS  Report  message. 

4.  Selection  of  any  highlighted  category  will  display  the 
designated  report  form.  The  cursor  is  positioned  to  the  right  of 
SQUADRON  and  data  entry  is  accomplished  as  previously  described. 
Figure  2  on  the  following  page  displays  the  first  page  of  the  OPHRS 
entry  form. 

5.  The  difference  between  the  Training  and  Readiness  and  Flight 
Hours  report  header  is  the  addition  of  a  HOME/DEPLOYED  field  on  the 
FLT  HRS  Report.  This  key  field  is  adjacent  to  YEAR  and  requires 
precise  entry,  either  "H"  for  HOME  or  "D"  for  DEPLOYED. 
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6.  Of  extreme  importance  is  the  consistency  with  which  data  is 
entered.  For  example,  in  Figure  2  there  is  a  category  field  for 
Operational  Flight  Hours,  an  Area  field  for  ASW,  a  type  field  for 
Indep  ASW  and  a  specific  type  field.  In  this  instance,  the  first 
three  fields  are  automatically  entered  in  the  database  by  entering 
data  in  the  fourth  field,  specific  type.  It  is  essential  the 
specific  type  be  entered  exactly  the  same,  including  upper  or  lower 
case,  for  all  squadrons  in  all  instances  of  a  report.  Any 
deviation  will  prohibit  effective  queries  because  the  data  will  be 
acknowledged  by  Paradox  as  being  a  different. 


OPERATIONAL  FLIGHT  HOURS 

SQUADRON  -  MONTH  YEAR  HOME /DEPLOYED 

A.  INDEP  ASW  SORTIES  ONSTA  TOTAL  CONT 

1. 

2. 

3. 

4. 

5. 

TOTAL 
SUM  TOTAL 

B .  COORD  ASW 

1. 

2  . 

3. 

4  . 

5. 

TOTAL 
SUM  TOTAL 


Flgrure 
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III.  EDITING  EXISTING  DATA 


ZTRAX  allows  users  to  edit  data  existing  in  the  database  tables 
by  selecting  the  edit  function  contained  in  both  the  Readiness  and 
Flight  Hour  menus. 

A.  Readiness  Report 

The  selection  process  for  EDIT  is  similar  to  ADD.  The  first 
step  is  to  select  Readiness  from  the  main  ZTRAX  menu. 


ADD  EDIT  VIEW 

EDIT  EXISTING  READINESS  REPORT  DATA 


Readiness  Main  Menu 


After  selecting  EDIT  from  the  menu,  the  following  three-step, 
three- screen  query  will  request  the  squadron,  month  and  year  of  the 
Readiness  Report  you  want  to  edit. 

ENTER  THE  SQUADRON  NUMBER:  _ 

ENTER  THE  MONTH:  _ 

ENTER  THE  YEAR:  _ 

Answering  the  three  requests  will  then  take  you  to  the  edit 
screen.  It  is  exactly  the  same  screen  display  as  the  ADD  data 
entry  form  except  the  data  is  already  there.  Any  field  can  be 
edited,  -ucluding  the  three  key  fields  squadron,  month  and  year. 
For  that  reason,  extreme  care  must  be  exercised  when  editing  any 
report.  To  complete  the  edit  press  the  [F2]  key  to  save  the  new 
data  and  exit  to  the  main  menu. 
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FLT  HRS  ADD  Menu 


After  one  of  the  above  categories  is  selected,  the  program  will 
request  the  following  four  identifying  items  to  determine  which 
record  to  retrieve  from  the  database. 

ENTER  THE  SQUADRON  NUMBER:  _ 

ENTER  THE  MONTH:  _ 

ENTER  THE  YEAR:  _ 

ENTER  "H"  FOR  HOME/"D"  FOR  DEPLOYED  _ 

An  EDIT  screen  is  exactly  the  same  as  the  ADD  screen  for  any 
specific  category.  Again,  all  fields  are  able  to  be  modified  so 
use  exercise  caution.  After  the  EDIT  is  complete,  press  the  [F2] 
key  to  save  the  new  data  and  ret\xrn  to  the  ZTRAX  main  menu. 
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IV.  QUERY  OPERATIONS 

Query  functions,  both  pre-defined  and  ad  hoc,  are  the  heart  of 
database  operations.  The  ability  to  easily  retrieve  required  data 
and  information  is  the  goal  of  any  application.  ZTRAX  provides 
several  pre-defined  queries  which  provide  information  on  specific 
categories  for  single  Readiness  or  Flight  Hour  report  records.  By 
exiting  ZTRAX  and  manipulating  the  Paradox  query  functions, 
multiple  records  can  be  queried  to  provide  the  requested 
information.  Part  A  outlines  the  pre-defined  queries.  Part  B 
outlines  and  demonstrates  some  of  the  Paradox  query  functions. 

A.  Pre- Defined  Queries 

ZTRAX  offers  several  pre-defined  queries  which  can  readily 
supply  information  on  individual  categories  for  specific  instances 
of  a  Flight  Hours  or  Readiness  report.  To  initiate  the  query 
function: 

1.  From  the  ZTRAX  main  menu  select  either  Readiness  or  Fit  Hrs, 
depending  upon  the  origin  of  the  data  you  want  to  obtain. 

Readiness  Queries 

2.  If  Readiness  is  chosen,  select  VIEW  from  the  main  menu. 


ADD  EDIT  VIEW 

VIEW  SPECIFIC  MONTHLY  READINESS  REPORT  INFORMATION 
Readiness  Main  Menu 


3.  The  Readiness  VIEW  menu  displays  six  different  options. 


MANNING  R- LEVELS  FLT  ACT  EXHRS  CONT  PERSTEMPO 
VIEW  MONTHLY  SQUADRON  MANNING  INFORMATION 


Readiness  View  Menu 
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4,  Following  the  selection  of  a  category  to  view,  ZTRAX  will 
request  the  following  information  to  determine  the  specific  data  to 
retrieve . 

ENTER  THE  SQUADRON  NUMBER:  _ 

ENTER  THE  MONTH:  _ 

ENTER  THE  YEAR:  _ 

5.  Completing  the  above  query  after  selecting  MANNING  from  the 
Readiness  VIEW  menu  will  display  the  following  screen  (Figure  3) . 
Similar  screens  are  displayed  for  all  menu  selections.  It  is 
essential  to  note  that  due  to  the  level  of  classification  of  this 
users  manual  (UNCLASSIFIED)  ,  none  of  the  fields  in  any  screen 
displays  in  this  manual  will  contain  data. 


SQUADRON  MANNING  INFORMATION 

SQUADRON  NN  MONTH  MMM  YEAR  YY 

MANNING  TOTAL  GAINS  LOSSES  CATI/CATII/CATIII 

PILOTS 

/  / 

NFOS 

/  / 

AIRCREW 

Figure  3 


6.  To  exit  the  query  screen,  press  the  [F2]  key  to  return  to  the 
main  ZTRAX  menu. 
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Fit  Hrs  Queries 

1.  Selecting  Fit  Hrs  from  the  main  ZTRAX  menu  will  display  the 
familiar  Fit  Hrs  main  menu.  Here,  to  view  any  of  the  predefined 
queries  you  must  first  select  Deployed  or  Home  from  this  menu. 
This  helps  Paradox  better  define  and  retrieve  the  request  for 
information. 


ADD  EDIT  DEPLOYED  HOME 
SELECTS  DEPLOYED  FLIGHT  HOUR  PATH 


Fit  Hrs  Main  Menu 


2.  Choosing  Deployed  or  Home  displays  essentially  the  same  menu  and 
options  with  the  word  Deployed  substituted  for  Home  in  each 
specific  case. 

OPHRS  TRNGHRS  EXHRS  SVCHRS  TOTALS 

VIEW  SPECIFIC  DEPLOYED  OPERATIONAL  FLIGHT  HOUR  INFORMATION 
FLT  HRS  DEPLOYED  Menu 

3. After  category  selection  is  complete,  type  selections  are  made 
dependent  upon  the  requirements.  For  OPHRS,  there  are  six  possible 
type  selections. 


ASW  INT/SUR  CCC  ELW  ASU  MISC 

DEPLOYED  OPERATIONAL  ASW  FLIGHT  HOUR  INFORMATION 

DEPLOYED  OPHRS  Menu 

4.  As  displayed  above.  Deployed  Operational  ASW  Flight  Hours 
have  been  selected.  This  selection  will  activate  the  built-in 
query  function  designed  to  identify  the  desired  information  in  the 
ZTRAX  tables. 


ENTER  THE  SQUADRON  NUMBER: 
ENTER  THE  MONTH: 

ELTER  THE  YEAR: 
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5.  After  entering  the  squadron,  month  and  year  of  the  desired 
report  ZTRAX  will  display  the  following  screen  (Figure  4)  for 
Deployed  Operational  ASW  Flight  Hours. 


DEPLOYBD  ASW  FLIGHT  HOURS 
SQUADRON  NN  MONTH  MMM  YEAR  YY 


INDEP  ASW  SORTIES  ONSTA  TOTAL  CONT 

1. 

2  . 

3. 

4. 

5. 

TOTAL 


COORD  ASW 

1. 

2. 

3  . 

4. 

5. 

TOTAL 


Figure  4 
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B.  Ad  Hoc  Queries 

Ad  hoc  queries  are  those  that  manipulate  the  actual  tables  of 
the  ZTRAX  database  to  retrieve  information.  Knowledge  of  using 
Paradox  Query  by  Example (QBE)  techniques  is  required  to  perform 
these  operations.  Training  in  these  procedures  is  available 
through  an  on-line  tutorial  program  provided  with  the  complete 
version  of  Paradox  3.5.  Additional  help  with  ad  hoc  queries  can  be 
received  by  depressing  the  [Fl]  Help  key  at  any  time  during  a  query 
operation. 

To  perform  a  query,  you  must  first  tell  Paradox  which  tables  the 
data  is  represented  in.  ZTRAX  is  comprised  of  eleven  tables  which 
retain  all  of  the  data.  The  following  is  a  list  of  the  tables  and 
the  data  represented  within  them. 

RDYRPT  Table  -  represents  a  Training  and  Readiness  report  for  a 
single  squadron,  month  and  year.  This  table  would  be  selected  to 
query  an  entire  report  for  comparative  purposes. 

FLTRPT  Table  -  represents  a  Flight  Hour  report  for  a  single 
squadron,  month  and  year.  As  above,  this  table  would  be  selected 
to  query  an  entire  report  for  comparative  purposes. 

ID  Table  -  represents  the  identifying  information  of  a  Training 
and  Readiness  or  Flight  Hour  report.  This  table  is  contained  in 
all  other  tables  to  differentiate  the  dat^ . 

MANNING  Table  -  represents  squadron  manning  levels  for  officer 
and  enlisted  aircrew.  It  is  derived  from  the  Training  and 
Readiness  report.  A  query  of  this  table  might  compare  pilot 
manning  levels  between  two  squadrons  for  the  same  month  and  year. 

INST  PILOTS  Table  -  represents  data  on  number  of  instructor 
pilots  a  squadron  has,  their  rank,  qualification  and  rotation 
dates.  A  sample  query  for  this  table  might  ask  for  all  the  pilots 
with  rotation  dates  after  a  specific  date.  This  table  is  derived 
from  the  monthly  Flight  our  report. 

NIGHTHRS  Table  -  represents  the  number  of  right  flight  hours  a 
squadron  completed  for  a  month  and  year  and  the  percentage  of  their 
total  flight  hours  were  night  hours.  This  table  is  derived  from 
the  Training  and  Readiness  report.  A  sample  query  might  ask 
for  the  average  number  of  night  flight  hours  for  all  the  squadron 
over  a  period  of  time. 
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R- LEVELS  Table  -  is  derived  from  the  Training  and  Readiness 
report.  It  represents  tactical  aircrew  readiness  levels (C- ratings) 
in  Primary  Mission  Areas  (PMA)  and  the  number  and  percentage  of 
crews  rated  C-1  for  a  squadron  during  a  report  month.  A  sample 
query  might  ask  for  the  number  of  C-1  rated  aircrews  a  squadron  has 
maintained  in  a  particular  PMA  over  the  last  year. 

DETOPS  Table  -  represents  various  data  related  to  detachment 
operations.  This  table  is  familiar  to  both  source  documents  with 
each  using  a  portion  of  the  fields  in  the  table.  Sample  queries 
can  display  multiple  squadron/aircraft/site  detachment  information. 

PILOT  STATS  Tab]e  -  represents  specific  facts  able  first  tour 
junior  officer  pilot  statistics.  It  is  familiar  to  the  Flight  Hour 
report  and  can  provide  comparative  analysis  of  squadrons  and  their 
pilot  training  programs,  if  queried. 

FLTHRS  and  MATRIX  Tables  -  these  table  represent  the  majority 
of  the  monthly  Flight  Hour  report.  FLTHRS  breaks  down  individual 
sorties  or  groups  of  sorties  into  categories,  areas,  types  and 
specific  types.  Matrix  then  assigns  the  number  of  sorties, 
onstation  hours,  total  hours  and  contingency  count  for  each  entity 
in  the  FLTHRS  table.  To  query  any  information  about  flight  hours 
the  first  step  is  to  determine  which  category  you  need.  Because 
ZTRAX  automatically  enters  several  of  these  fields  during  the 
initial  data  entry  process  the  names  used  for  category,  area,  type 
and  specific  type  must  be  precisely  the  same  when  queried.  The 
following  pages  contain  the  names  ZTRAX  uses  for  these  fields.  The 
only  field  entered  by  the  user  during  data  entry  is  specific  type. 
This  must  be  entered  consistently  every  time  or  the  resulting 
queries  will  be  incorrect. 


The  first  example  is  the  body  of  a  Training  and  Readiness 
report.  This  is  where  all  the  raw  data  is  contained.  The 
identifying  numbers  and  letters  correspond  exactly  to  those  on  an 
actual  report.  Beside  each  number  is  a  brief  explanation  of  which 
cable  the  data  is  located  in  and  the  recommended  field  and  record 
names  to  use  for  queries.  Familiarity  with  the  Paradox  query  by 
example  techniques  are  required  to  complete  an  query  operation. 
The  first  section  of  the  Training  and  Readiness  report  below  will 
briefly  describe  the  necessary  procedures  to  use  QBE.  Two  complete 
query  screen  examples  will  follow  the  Flight  Hour  report  fields 
example . 
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1.  MONTHLY  TRAINING  and  READINESS  REPORT 


1 .  This  i 3  the  header  of  the  report .  The  ID  table  represents 
this  data  and  will  be  required  for  all  queries  of  this  report.  To 
query  this  section  of  the  report  place  check  marks  on  the  Paradox 
query  screen  under  SQUADRON,  MONTH  and  YEAR.  Below  the  check  marks 
in  each  field  place  an  example  of  the  data  you  want  to  retrieve, 
for  example;  if  you  want  information  about  Patrol  Squadron  Nineteen 
for  the  month  of  January,  1990  you  would  place  a  19  underneath  the 
check  mark  for  SQUADRON,  a  JAN  underneath  the  check  mark  for  MONTH 
and  a  90  underneath  the  check  mark  for  YEAR. 

2.  This  section  concerns  squadron  manning.  Data  is  found  in 
the  MANNING  table.  To  query,  under  the  position  field  place  either 
PILOT,  NFO  or  AIRCREW  and  check  either  GAINS,  LOSSES,  TOTAL,  CAT  I, 
CAT  II  or  CAT  IIT. 

3.  This  section  concerns  squadron  readiness  levels  by  PMA. 
Data  is  found  in  the  R- LEVELS  table.  To  query,  under  the  PMA  field 
place  any  one  of  the  nine  PMA's  then  place  check  marks  under  C- 
RATING,  CREWS  and  PERCENTAGE,  as  required  for  your  query. 

4.  This  sections  contains  night  flight  hour  data  and  is  found 
in  tha  NIGHTHRS  table.  To  query,  place  checks  under  both  NIGHT 
HOURS  and  %  OF  TOTAL. 

5.  This  section  contain  data  about  the  breakdown  of  flight  hours 
for  the  report  period.  The  data  is  found  in  two  tables,  the 
FLTHOURS  table  and  MATRIX  table.  To  query,  first  retrieve  the 
FLTHOURS  table.  Place  checks  under  CATEGORY  and  use  the  following 
as  examples  of  the  query,  depending  on  your  requirements,  TRNGKRS 
for  Training  Hours,  OPHRS  for  Operational  Hours,  SVCHRS  for  Service 
Hours,  EXHRS  for  Exercise  Hours,  CONHRS  for  Contingency  Hours  and 
ICTALHRS  for  Total  Flig;  '■  Hours.  Then  select  the  MATRIX  table  and 
plai.e  a  check  under  TOTAL  for  total  hours. 

6.  7,  8.  Data  for  these  three  area  are  all  obtained  from  the 
same  table,  DETOPS.  To  query  these,  place  check  marks  under  the 
required  fields  and  then  place  examples,  as  required  by  your  query. 
The  following  fields  correspond  to  the  various  items  of  items  6, /, 
and  8.  DET  TYPE  represents  an  Exercise  or  Contingency (items  6  and 
7)  .  DET  NAME  is  the  detachment  name  and  is  used  for  all  three 
items.  DATE  is  the  date  of  detachment  and  used  by  all  thr<^e  items. 
TOTAL  HRS  is  only  used  by  item  6,  Exercise,  and  represents  the 
total  flight  hours  involved  with  the  detachment.  #DAYS  is  only 
used  by  item  8,  Perstempo,  to  indicate  length  of  detachment. 


2.  MONTHLY  FLIGHT  HOUR  REPORT 


The  monthly  Flight  Hour  report  differs  somewhat  from  the 
Training  and  Readiness  report  because  the  majority  of  the  data  is 
stored  in  two  tables,  FLTHRS  and  MATRIX.  This  results  from  the 
fact  that  the  majority  of  data  in  this  report  involves  flight 
hours.  It  is  essential  to  indicate  precisely  the  data  you  want  to 
obtain  in  the  query.  Correct  and  consistent  usage  of  field  names 
during  the  data  entry  stage  will  result  in  the  ability  to 
effectively  query  this  data.  The  following  provides,  in  a  sequence 
relative  to  the  Flight  Hour  report  source  document,  the  field  names 
used  by  ZTRAX  and  the  recommended  record  entries  for  various  flight 
hour  categories,  areas,  types  and  specific  types. 

I.  TASKED  OPERATIONAL  HOURS 

To  query  all  the  information  in  this  category,  on  the  FLTHRS 
table  query  form  check  the  CATEGORY  field  and  place  the  example 
OPHRS  below  the  check  mark. 

A.  Independent  ASW  is  queried  by  placing  a  check  under  AREA  and 
placing  ASW  below  it,  then  checking  TYPE  and  placing  INDEP  below 
the  check.  Because  there  are  many  types  of  Independent  ASW,  the 
SPECIFIC  TYPE  field  will  separate  them.  Place  a  check  under 
SPECIFIC  TYPE  and  place  the  name  of  the  SPECIFIC  TYPE  you  want  to 
query.  Of  great  importance  here  is  the  consistent  use  of  the  same 
manes  for  SPECIFIC  TYPES  over  the  course  of  using  this  program.  It 
is  recommended  they  be  documented  in  the  space  provided  at  the  end 
of  this  chapter  of  the  manual. 

After  completing  the  FLTHRS  portion  of  the  query  retrieve  the 
MATRIX  table.  Here  you  can  place  check  marks  in  any  of  the  desired 
fields  you  require.  There  are  no  examples  required  for  the  MATRIX 
table . 

B.  Coordinated  ASW  works  exactly  like  the  above  example.  Place 
ASW  under  the  AREA  check  mark  and  COORD  under  the  TYPE  field  check 
mark.  SPECIFIC  TYPE  is  as  previously  outlined.  After  this  is 
completed,  again  go  to  the  MATRIX  table  to  select  your  query 
choices . 

C.  Combined  ASW  uses  COMB  in  the  TYPE  field.  The  rest  remains 
as  previously  described. 

D.  Indep-^ndent  INT/SUR  uses  INT/SUR  in  the  AREA  field  and  INDEP 
in  the  TYPE  field.  No  SPECIFIC  TYPE  is  available. 

E.  Coordinated  INT/SUR  uses  INT/SUR  in  the  AREA  field  and  COORD 
in  the  TYPE  field.  No  SPECIFIC  TYPE  is  available. 

F.  Combined  INT/SUR  uses  INT/SUR  for  the  AREA  field  and  COMB  in 
the  TYPE  field.  No  SPECIFIC  TYPE  is  available. 
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G.  CCC  is  used  in  the  AREA  field.  No  TYPE  or  SPECIFIC  TYPE  are 
required. 

H.  Combined  CCC  uses  CCC  in  the  AREA  field  and  COMB  in  the  TYPE 
field.  No  SPECIFIC  TYPE  is  available. 

I.  ELW  is  used  in  the  AREA  field.  No  TYPE  or  SPECIFIC  TYPE  are 
required. 

J.  Coordinated  ELW  uses  ELW  in  the  AREA  field  and  COORD  in  the 
TYPE  field.  SPECIFIC  TYPE  is  not  available. 

K.  Combined  ELW  uses  ELW  in  the  AREA  field  and  COMB  in  the  TYPE 
field.  SPECIFIC  TYPE  is  not  available. 

L.  ASU  is  used  for  the  AREA  field.  TYPE  and  SPECIFIC  TYPE  are 
not  available. 

M.  Coordinated  ASU  uses  ASU  for  the  AREA  field  and  COORD  in  the 
TYPE  field.  SPECIFIC  TYPE  is  not  available. 

N.  Combined  ASU  uses  ASU  for  the  AREA  field  and  COMB  for  the 
TYPE  field.  SPECIFIC  TYPE  is  not  available. 

O.  Deployment  Transit  uses  DEPXSIT  for  the  AREA  field.  No  other 
fields  are  available. 

P.  Detachment  Transit  uses  DETXSIT  for  the  AREA  field.  No  other 
fields  are  available. 

Q.  Pony  Express  is  used  in  the  AREA  field.  No  other  fields  are 
used . 

R.  Log  Support  is  used  in  the  AREA  field  and  the  names  of 
various  Log  Support  events  are  contained  in  SPECIFIC  TYPE.  There 
is  no  entry  for  TYPE. 

S.  Other  is  used  in  the  AREA  field  and  the  various  Other  names 
are  contained  in  SPECIFIC  TYPE.  There  is  no  entry  for  TYPE. 

T.  Total  Contingency  uses  TOTAL  CONT  in  the  AREA  field.  There 
is  no  use  of  TYPE  or  SPECIFIC  TYPE  for  this  area. 

U.  Total  Operational  uses  TOTAL  OP  in  the  AREA  field.  There  is 
no  use  of  TYPE  or  SPECIFIC  TYPE  for  this  area. 
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II.  INDEPENDENT  TRAINING  HOURS 


To  query  the  data  in  this  category  use  INDEP  TRNGHRS  for  the 
CATEGORY  in  the  FLTHRS  table.  As  above,  after  filling  the 
appropriate  blocks  in  FLTHRS,  retrieve  MATRIX  and  checks  the 
necessary  blocks  as  required. 

A.  ASW  is  the  AREA  field  and  is  used  in  the  following  1-5. 

1.  CAST  is  the  TYPE  field. 

2.  A-37  is  the  TYPE  field. 

3.  NIB  is  the  TYPE  field. 

4.  OTHER  is  the  TYPE  field.  Use  SPECIFIC  TYPE  to  specify 
the  event  ypu  require. 

5.  TOTAL  ASW  is  the  TYPE  field. 


B.  INT/SUR  is  the  AREA  field  for  the  following  1-3. 

1.  A- 30  is  the  TYPE  field. 

2.  OTHER  is  the  TYPE  field.  Use  SPECIFIC  TYPE  for  the  event 
you  require. 

3.  TOTAL  INT/SUR  is  the  TYPE  field. 

C.  MIW  is  the  AREA  field  and  ..sed  in  the  following  1-4. 

1.  A-38  is  the  TYPE  field. 

2.  MRCI/WKUP  is  the  TYPE  field. 

3.  OTHER  is  the  TYPE  field.  Use  SPECIFIC  TYPE  for  the  event 
you  require . 

4.  TOTAL  MIW  is  the  TYPE  field. 

D.  ELW  is  the  AREA  field,  SPECIFIC  TYPE  lists  specific  events. 

E.  ASU  is  the  AREA  field,  SPECIFIC  TYPE  lists  specific  events. 

F.  BOMBEX  is  the  AREA  field,  SPECIFIC  TYPE  lists  specific 
events . 

G.  TOTAL  TRAINING  is  the  AREA  field.  No  TYPE  or  SPECIFIC  TYPE 
is  required. 

III.  PILOT/CREW  TRAINING  HOURS 

To  query  data  in  this  category  use  PCTRNG  for  CATEGORY  in  the 
FLTHRS  table.  After  filling  in  the  appropriate  fields,  use  the 
MATRIX  table  to  specify  the  information  you  need. 

A.  PILOT  TRAINING  is  the  AREA  field.  Use  it  for  the  following 
1-6  items. 

1.  SYLLABUS  is  the  TYPE  field. 

2.  PPT  is  the  TYPE  field. 

3.  INSTRUMENT  is  the  TYPE  field. 

4.  AIRWAYS  is  the  TYPE  field. 
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5.  NATOPS  is  the  TYPE  field. 

6.  TOTAL  is  the  TYPE  field. 

B.  CREW  TRAINING  is  the  AREA  field.  Use  it  for  the  following  1- 
4  items. 

1.  SYLLABUS  is  the  TYPE  field. 

2.  OVRWTRNAV  is  the  TYPE  field. 

3.  NATOPS  is  the  TYPE  field. 

4.  TOTAL  is  the  TYPE  field. 

C.  TOTAL  is  the  AREA  field.  This  retrieves  total  figures  for 
Pilot  Crew  training. 


IV.  MISCELLANEOUS  TRAINING  HOURS 

To  query  data  form  this  category  use  MISCTRNG  in  the  CATEGORY 
field  of  FLTHRS.  The  use  of  the  MATRIX  table  is  the  same  as 
previously  described. 

A.  MAINT  CHECK  is  the  AREA  field. 

B.  MAD  COMP  is  the  AREA  field. 

C.  WST  TRANSIT  is  the  AREA  field. 

D.  SCHOOL  FLTS  is  the  AREA  field. 

E.  FERRY  is  the  AREA  field. 

F.  OTHER  is  the  AREA  field.  SPECIFIC  TYPE  is  used  to  specify 
each  named  event . 

G.  TOTAL  is  the  AREA  field. 


V.  TOTAL  TRAINING  is  the  CATEGORY.  There  are  no  AREA  or  TYPE 
fields  relative  to  this  category. 


VI.  COORD/COMBINED  EXERCISES 

Exercise  is  the  CATEGORY  name  for  this  field.  There  are  two 
TYPE  fields  associated  with  this  section,  COORD  for  Coordinated  and 
COMB  for  Combined. 

A.  COORD  is  the  TYPE  field,  ASW  is  the  AREA  field.  SPECIFIC 
TYPE  lists  the  various  events  for  the  category.  It  is  essential 
all  SPECIFIC  TYPE  names  coincide  with  the  terms  used  during  data 
entry . 

B.  COORD  is  the  TYPE  field,  INT/SUR  is  the  AREA  field.  SPECIFIC 
TYPE  lists  the  various  events  in  this  area. 

C.  COORD  is  the  TYPE  field,  CCC  is  the  AREA  field.  SPECIFIC 
TYPE  lists  the  various  events  in  this  area. 

D.  COORD  is  the  TYPE  field,  ASU  is  the  AREA  field.  SPECIFIC 
TYPE  lists  the  various  events  in  the  area. 
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E.  COORD  is  the  TYPE  field,  MIW  is  the  AREA  field.  SPECIFIC 
TYPE  lists  the  various  events  in  the  area. 

F.  COORD  is  the  TYPE  field,  TOTAL  is  the  AREA  field. 

G.  COMB  is  the  TYPE  field,  ASW  is  the  AREA  field.  SPECIFIC  TYPE 
lists  the  various  events  in  the  area. 

H.  COMB  is  the  TYPE  field,  INT/SUR  is  the  AREA  field.  SPECIFIC 
TYPE  lists  the  various  events  in  the  area. 

I.  COMB  is  the  TYPE  field,  CCC  is  the  AREA  field.  SPECIFIC  TYPE 
lists  the  various  events  in  the  area. 

J.  COMB  is  the  TYPE  field,  ASU  is  the  AREA  field.  SPECIFIC  TYPE 
lists  the  various  events  in  the  area. 

K.  COMB  is  the  TYPE  field,  MIW  is  the  AREA  field.  SPECIFIC  TYPE 
lists  various  events  in  the  area. 

L.  COMB  is  the  TYPE  field,  TOTAL  is  the  AREA  field. 

M.  TOTAL  is  the  TYPE  field. 


VII.  SERVICES 

To  query  this  category  use  SVCS  in  the  field  for  CATEGORY. 
After  all  other  query  information  for  FLTHRS  is  complete,  then  USE 
the  MATRIX  table  to  identify  the  data  you  need. 

A.  C/N  is  the  AREA  field. 

B.  ACFT  SVCS  is  the  AREA  field. 

C.  SAR  is  the  AREA  field. 

D.  CNO  PROJECTS  is  the  AREA  field,  SPECIFIC  TYPE  lists  the 
various  projects  in  this  area. 

E.  TAC  D&E  is  the  AREA  field,  SPECIFIC  TYPE  lists  the  various 
Tac  D&E  projects  in  this  area. 

F.  RECRUITING  is  the  AREA  field. 

G.  STATIC  DISPLAY  is  the  AREA  field. 

H.  ORIENT/DEMO  is  the  AREA  field. 

I.  STAFF  SUPPORT  is  the  AREA  field. 
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J.  OTHER  is  the  AREA  field,  SPECIFIC  TYPE  identifies  the 
various  entries  for  this  area. 

K.  TOTAL  is  the  AREA  field. 

VIII.  TOTAL  FLIGHT  HOURS 

TOTALS  is  the  CATEGORY  field  for  this  section  of  the  report. 
The  data  is  found  in  the  FLTHRS  and  MATRIX  tables. 

A.  HOME  is  the  AREA  field. 

B.  DEPLOYED  is  the  AREA  field. 

C.  TOTAL  is  the  AREA  field. 


IX.  MONTHLY  PILOT  ANALYSIS 
To  query  this  section  use  the  PILOT  STATS  table. 

A.  1ST  PILOT  TIME.  Place  a  check  under  this  field  to  query  1st 
Pilot  Time. 

B.  DEFICIENT  PILOTS.  Place  a  check  under  this  field  to  query 
1st  Tour  Pilots  <  10  Hours  1st  Pilot  Time. 

C.  PEF.  Place  a  check  mark  under  this  field  to  query  1st  Tour 
PEF  Pilots. 

D.  IP  STATUS  uses  the  INST  PILOTS  table  to  maintain  its  data. 
To  query  this  data: 

1.  Place  a  check  mark  under  RANK  and  enter  the  rank  of  the 
instructor  pilots  you  want  to  search. 

2.  Place  a  check  mark  under  DESIGNATION. 

3.  Place  a  check  mark  under  PRD. 


X.  MONTHLY  DETACHMENT  OPERATIONS 

To  query  this  section  use  the  DETOPS  table (items  1-4,9)  and  the 
FLTHRS  and  MATRIX  tables (items  5-8).  As  explained  before,  place 
check  marks  below  the  fields  you  desire  then  place  examples 
underneath  the  checks.  Imperative  here  is  that  data  entry  names 
exactly  coincide  with  query  example  names. 

1.  SITE  is  an  alphabetic  name  for  the  detachment  site. 

2.  I^A/C  is  a  numeric  entry  for  the  number  of  aircraft  present  at 
the  site. 

3 .  SCREWS  is  a  numeric  entry  for  the  number  of  aircrew  present 
at  the  detachment  site. 

4.  #DAYS  is  a  numeric  entry  for  the  number  of  days  a  detachment 
has  been  operational. 
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5.  OPHRS  is  a  numeric  entry  of  flight  hours.  Use  OPHRS  for  the 
CATEGORY  field  of  FLTHRS,  TOTAL  from  the  MATRIX  table. 

6.  TRNGHRS  in  the  CATEGORY  field,  TOTAL  from  the  MATRIX  table. 

7.  EXHRS  in  the  CATEGORY  field,  TOTAL  from  the  MATRIX  table. 

8.  SVCHRS  in  the  CATEGORY  field,  TOTAL  from  the  MATRIX  table. 

9.  P/C  POSIT  is  the  TOTALHRS  field  in  DETOPS.  This  gives  the 

transit  time  to  the  detachment. 
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The  use  and  manipulation  of  Paradox  query  by  example  techniques 
are  profiled  extensively  in  the  Paradox  Users  Manual  that 
accompanies  the  program  documentation.  The  following  examples  are 
based  directly  from  that  manual  and  reflect  the  operation  of  the 
Paradox  program,  not  ZTRAX.  Therefore,  familiarity  with  Paradox 
query  operations  is  essential  prior  to  attempting  any  queries  with 
ZTRAX. 

The  query  charts  on  the  previous  pages  specified  the  various 
tables  to  query  for  information  in  a  particular  case.  It  also 
provided  the  field  naimes  ZTRAX  uses  in  very  specific  instances. 
Now,  two  examples  of  ZTRAX  ad  hoc  queries  will  be  shown.  The  first 
is  a  single  query,  the  second  is  a  multiple  query.  Both  will 
follow  the  same  format,  first  will  be  a  description  of  the 
requested  information,  next  the  tables  and  required  fields  for  the 
query  will  be  identified  using  the  query  charts,  and  last,  query 
screen  displays,  with  explanations,  will  be  provided. 

3 .  SINGLE  QUERY 

This  first  example  will  be  a  relatively  simple  query  to 
reinforce  the  Paradox  query  by  example  techniques  and  allow  you  to 
get  a  feel  for  finding  field  names  in  the  query  charts. 

Problem:  You  want  to  find  out  the  total  number  of  sorties  for 
tasked  operational  flight  hours  for  independent  ASW  during  the  home 
cycle  for  Patrol  Squadron  1,  for  the  month  of  JAN  1991. 

STEP  1  -  From  the  PARADOX  main  menu  select  ASK. 


View  ASK  Report  Create  Modify  Image  Forms  Tools  Scripts  Help 
PARADOX  Main  Menu 


STEP  2  -  From  the  Ask  menu,  enter  the  table  naime  which  you  wish 
to  query,  in  this  case  FLTHRS. 
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Table:  FLTHRS  Main 

ASK  Menu 


*[F6]  to  include  a  field  in  the  ANSWER;  [F5]  to  give  an  example 


=FLTHRS=====SQUADRON=======MONTH=======yEAR======STATUS 

=  *  1  =  *  JAN  =  *  91  =  *  HOME 


FLTHRS===CATEGORY===AREA======TYPE===SPECIFIC  TYPE===SORTIES 

=  *  OPHRS  =  *  ASW  =  *  INDEP={NO  ENTRY  REQD) =  * 


Paradox  Query  Form 


STEP  3  -  The  display  above  is  the  Paradox  query  form.  It  is 
reproduction  of  the  FLTHRS  table  in  tabular  format.  An  asterisk 
has  been  substituted  for  the  check  mark  normally  found  in  Paradox. 
You  can  run  the  entire  length  of  the  table  by  using  the  right  arrow 
key.  The  first  step  in  this  query  is  to  identify  the  key  fields 
squadron,  month,  year  and  status.  This  has  been  done  as  shown  in 
the  top  portion  cf  the  form.  Next,  identify  the  CATEGORY,  AREA  and 
TYPE  and  place  the  examples  as  shown.  Notice  SPECIFIC  TYPE  is  not 
required  by  this  query.  After  all  entries  are  complete  press  the 
FF2]  to  activate  the  query.  Paradox  will  then  display  the  output 
screen  shown  below.  At  this  point  you  also  have  the  option  of 
printing  the  screen  display.  Those  procedures  are  outlined  in  the 
Paradox  manual . 
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ANSWER  SQUADRON  MONTH  YEAR  STATUS  CATEGORY  AREA  TYPE  SORTIES 
1  =  1  =  JAN  =  91  =  HOME  =  OPHRS  =  ASW  =INDEP=  20 


4 .  MULTIPLE  QUERY 

This  example  will  show  a  typical  multiple  query  ZTRAX  might  be 
asked  to  provide.  The  format  will  be  the  same  as  Example  1. 

Problem:  You  want  to  compare  Pilot  manning  statistics  for  two 
different  squadrons  for  the  month/year  JAN  91. 

Step  1  -  From  the  Paradox  main  menu  select  the  ASK  option. 

Step  2  -  From  the  ASK  main  menu  enter  the  table  to  be  used  for 
the  query.  In  this  case  the  data  comes  from  the  monthly  Training 
and  Readiness  report.  You  determine  the  MANNING  table  holds  the 
information  you  desire  so  enter  Manning  at  the  prompt. 

Table:  MANNING  Main 

Ente^^iam^^^tabl^^^^sl^abou^^^^^res^^enter^^t^^e^^a^^^^^ 

ASK  Menu 

Step  3  -  Knowing  the  query  function  requires  the  key  fields  to 
be  entered,  do  that  first  for  both  squadrons.  Next,  the  data  about 
Pilot  manning  is  in  the  POSITION  field,  put  a  check  under  POSITION 
and  the  example  PILOT  beside  it.  All  pilot  statistics  are  desired 
so  place  check  marks  in  GAINS,  LOSSES,  TOTAL,  CAT  I,  CAT  II  and  CAT 
III.  Do  this  twice,  once  for  each  squadron.  Press  [F2]  when  the 
form  is  completed  and  receive  the  answer. 
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*  [F6]  to  include  a  field  in  the  ANSWER;  [F5]  to  give  an  excimple 


=MANNING===SQUADRON=======MONTH=======YEAR======STATUS===== 

=  *  17  =  *  JAN  =  *  91  =  *  HOME 

=  *  1  =  *  JAN  =  *  91  =  *  HOME 


=POSITION===TOTAL===GAINS===LOSSES===CATI===CATII===CATIII== 
♦PILOT  =  *  =  *  =  ♦  =  * 

it  ^  it  =  it  ^  it  ^  it  ^  it  ^  it 


Paradox  Query  Form 


The  answer  to  the  above  query  looks  like  this.  After  you  have 
completed  this  cpaery  prejs  the  [F8]  key  to  clear  the  screen  and 
return  to  the  main  Paradox  menu. 


ANSWER  SQUADRON  MONTH  YEAR  STATUS  POSITION  TOTAL  GAINS  LOSSES 

1  =  17  =  JAN  =  91  =  HOME  =  PILOT  =  33  =  3  =  5 

2  =  1  =  JAN  =  91  =  HOME  =  PILOT  =  32  =  4  =  3 


Notice  the  entire  query  does  not  fit  on  the  page.  Using  the 
left/right  arrow  keys  you  can  view  the  remainder  of  the  query. 
This  is  a  screen  limitation  imposed  by  Paradox. 

Two  Soimple  queries  have  provided  some  insight  into  effectively 
utilizing  the  Paradox  ASK  function.  Further  reference  can  be 
obtained  in  the  Paradox  Users  Manual. 
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V.  GRAPHICAL  OUTPUTS 

Paradox  allows  a  users  to  display  any  data  from  Paradox  and 
ZTRAX  tables  on  a  variety  of  business  style  graphs,  such  as  pie, 
bar,  area,  line  and  mixed  charts.  Procedures  for  defining  and 
using  graphs  are  found  in  the  Paradox  users  manual.  This  chapter 
will  provide  a  brief  overview  of  integrating  Lotus  1-2-3,  Quattro 
Pro  and  dBase  II,  III  or  IV  and  Ascii  formatted  files  into  or  from 
a  Paradox  database  table. 

The  Tools  selection  found  in  the  Paradox  main  menu  contains  an 
Export/Import  option.  This  allows  you  to  transfer  data  to  and  from 
other  software  systems.  After  selecting  the  Import/Export  option 
you  have  the  two  following  choices: 

EXPORT  IMPORT 

Selecting  either  of  these  options  displays  the  following  submenu: 

QUATTRO  PRO  1-2-3  SYMPHONY  dBASE  PFS  REFLEX 

VISICALC  ASCII 

An  important  point  here  is  that  Paradox  always  converts  the  data  to 
Paradox  format  through  copying  the  entire  file,  that  way  the  data 
is  left  unchanged,  an  allowing  you  to  rename  the  file  for  Paradox's 
purposes . 

The  selection  Quattro  Pro  allows  you  to  import  data  from  a 
spreadsheet  into  a  Paradox  table,  or  export  a  Paradox  table  into  a 
Quattro  spreadsheet.  When  importing  spreadsheet  data  into  Paradox, 
remember  Paradox  stores  information  in  even  row  and  columns  whereas 
a  spreadsheet  lets  you  arrange  the  text,  numbers  and  formulas  in 
any  manner  you  desire. 

Selecting  1-2-3  from  the  above  submenu  and  you  receive  these 
options : 

1)  1-2-3-RELEASE  lA  2}  1-2-3-RELEASE  2 

Here  you  select  the  appropriate  option  for  the  version  of  1-2- 
2  you  will  use.  Paradox  allows  you  to  import  and  export  data  as 
described  above.  Be  sure  to  specify  the  correct  directories  when 
copying  to  and  from  a  hard  drive  to  avoid  confusing  your  files.  As 
before,  Paradox  cannot  import  randomly  place  data  in  a  spreadsheet. 
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It  must  import  by  columns  and  rows,  where  the  top  row  contains 
field  names  for  the  database  table.  If  your  spreadsheet  contains 
labels  or  formulas  outside  of  a  column/row  orientation,  you  should 
use  the  File  Xtract  option  discussed  in  the  Paradox  users  manual. 

Transferring  to  and  from  dBase  applications  is  a  simple  process 
because  both  programs  store  data  in  rows  and  columns  (records  and 
fields) .  Selecting  dBase  from  the  options  menu  will  display  the 
following: 

dBASE  II  dBASE  III 

Paradox  will  copy  the  data  to  the  file  name  you  have  provided 
with  a  DBF  extension.  Importing  dBase  files  are  just  a  simple, 
however  dBase  logical  fields  will  be  converted  to  Paradox 
alphanumeric  fields  with  a  length  of  one  character  and  memo  fields 
will  be  trimmed  to  a  maximum  of  255  characters  and  stored  as 
alphanumeric  data. 

Paradox  also  allows  the  Import/Export  of  ascii  coded  files. 
Selecting  the  Ascii  option  of  the  Import/Export  menu,  then 
selecting  Export  displays  the  following: 

DELIMITED  TEXT 

Selecting  the  Import  option  of  the  Ascii  menu  displays  the 
following : 

DELIMITED  APPEND /DELIMITED  TEXT 

Delimited  import/export  of  text  is  used  for  software 
applications  that  can  only  import/export  ascii  formatted  files.  To 
use  this  option  you  would  first  create  a  delimited  export  file, 
then  import  it  into  the  other  software  application  you  want  to  use. 
The  Paradox  users  manual  specifically  outlines  these  procedures. 
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VI.  PROGRAM  MAINTENANCE 

Program  maintenance  of  ZTRAX  was  designed  to  be  as  easy  as 
possible.  To  change  any  tables,  scripts  or  input/output  screen 
displays  you  will  use  Paradox  Personal  Programmer  (PPROG) . 

A.  Perfective  Maintenance 

To  Start  PPROG;  from  the  DOS  prompt  change  directories  to  ZTRAX. 
This  will  place  all  the  ZTRAX  tables  in  the  current  directory. 

C:\ZTRAX 

Then  type  a  path  statement,  as  follows: 

C:\ZTRAX  >  PATH=C : \PDOX35 ; C : \PDOX35\PPROG; 

This  will  load  PPROG  in  RAM  along  with  ZTRAX.  Start  PPROG  by 
typing  "PPROG"  at  the  DOS  prompt. 

The  initial  PPROG  screen  will  allow  the  follow  options: 

CREATE  MODIFY  SUMMARIZE  REVIEW  PLAY  TOOLS  QUIT 
Select  the  Modify  option  and  type  ZTRAX  at  the  prompt.  PPROG  will 
load  the  ZTRAX  menu  structure  and  display  the  ZTRAX  main  menu  on 
the  screen  with  several  edit  options.  Prior  to  initializing  PPROG 
you  should  have  determined  exactly  what  you  want  to  modify  in 
ZTRAX.  The  entire  prograim  is  able  to  be  modified  through  PPROG  so 
exercise  caution  when  doing  so. 

Guidance  on  using  PPROG  is  contained  in  the  Paradox  users  manual 
however  it  is  not  the  only  way  to  modify  ZTRAX.  For  instance,  to 
add  a  new  field  to  a  ZTRAX  table  you  must  retrieve  the  table  from 
the  Paradox  main  menu  and  modify  it  but  then  you  will  have  to 
modify  the  input  and  edit  screens  for  the  new  field  ,  this  is  more 
difficult  to  accomplish  in  Paradox  than  in  PPROG.  It  is 
recommended  PPROG  be  used  for  all  program  modifications  except 
modifying  the  tables.  Below,  for  reference  purposes,  is  a  sample 
ZTRAX  program  modification. 

Problem:  Adding  a  new  numerical  field  called  AVERAGE  in  the 
MANNING  table.  This  field  will  be  a  required  entry  on  the  data 
input  form  and  represents  the  average  number  of  aircrew  personnel 
in  a  specific  position  for  the  previous  twelve  months. 
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STEP  1  -  Adding  the  new  field  to  the  MANNING  table  is  simple. 
From  the  Paradox  main  menu  you  retrieve  the  MANNING  table,  select 
edit,  and  add  the  new  field  where  it  is  required.  In  this  case,  we 
would  add  the  new  field,  AVERAGE,  immediately  before  the  TOTALS 
field.  Because  this  new  field  is  numeric,  simply  enter  an  N  in  the 
field  type  coliunn,  shown  below.  Press  the  [F2]  key  when  coit^lete. 


Modify  MANNING  Table 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

STRUCT==========FIELD  NAME==============FIELD  TYPE======== 

4  =  POSITION  =  A7 

5  =  AVERAGE  =  N 

6  =  TOTAL  =  N 

7  =  GAINS  =  N 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 


MANNING  Table 


STEP  2  -  Now  that  the  table  has  been  modified,  start  the  PPROG 
application  as  hown  above.  Next,  select  modify  and  type  ZTRAX  at 
the  prompt.  You  will  be  presented  with  the  following  PPROG  Modify 
edit  screen: 


Tables  Men\iActlon  NotDefined  SplashScreen  DO- IT  Cancel 
Modify  a  menu  selection  of  an  action  associated  with  a  menu 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

===============The  Paradox  Personal  Programmer=============== 

Modifying  ZTRAX  Application 

TABLES  allows  you  to  add  or  remove  one  or  more  tables 
MENUACTION  allows  you  to  modify  the  selection/actions  in  menu 
NOTDEFINED  takes  you  to  the  first  undefined  menu  selection 
SPLASHSCREEN  allows  you  to  modify  an  application's  first  screen 
DO- IT!  saves  all  changes  you  have  made  to  the  application 
PPROG  Modify  Menu 


STEP  3  -  Select  MENUACTION  from  the  screen  above,  this  will 
display  the  screen  shown  below. 


READINESS  FLTHRS  Leave 
MONTHLY  READINESS  REPORT 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

===============The  Paradox  Personal  Programmer=============== 

Modifying  ZTRAX  Application 

Pick  the  menu  selection  you  want  to  modify. 

Use  the  <-  ->  keys  to  move  around  the  display 

Press  I (ENTER)  to  move  down  a  menu  level,  [ESC]  to  move  up 

When  the  menu  selection  you  want  to  modify  is  highlighted, 
press  [FIO]  to  display  the  action  menu,  then  select  the  type 
of  modification  you  want  to  make. 


PPROG  MenuAction  Menu 


STEP  4  -  The  next  step  is  to  press  the  [FIO]  key  to  retrieve  the 
action  menu  as  shown  below. 


93 


Menu  Action  DO -IT!  Cancel 
Modify  the  current  menu  action 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

X  READINESS  FLTHRS  Leave  X 

X  MONTHLY  READINESS  REPORT  X 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

===============The  Paradox  Personal  Programmer=============== 

Modifying  ZTRAX  Application 
Current  menu  level  :  MAIN 

Specify  whether  you  want  to  modify  a  menu  or  an  action. 

Menu  allows  you  to  modify  the  current  menu  level.  You  can  add 
new  selections,  edit  existing  selections,  or  delete  selections. 
If  you  delete  a  menu  selection,  all  actions  or  lower- level 
menus  attached  to  that  selection  will  be  deleted  as  well. 

ACTION  allows  you  to  modify  the  action  associated  with  the 
current  menu  selection. 

DO- IT!  save  the  modifications  you  have  specified  to  this 
point . 

PPROG  MenuAction  Menu 


STEP  5  -  Next,  select  ACTION  from  the  previous  menu  and  the 
following  menu  appears.  From  this  next  menu  you  will  select  Revise 
with  the  cursor  highlighting  ADD. 

STEP  6  -  Selecting  REVISE  will  place  another  screen  display  from 
which  you  will  have  two  options:  keep  or  modify  the  existing  table 
or  view.  By  selecting  modify  you  can  select  the  MANNING  table  and 
make  the  new  field  entry,  as  we  have  already  done  in  Paradox,  or 
select  keep  the  current  table  and  then  move  to  the  next  menu 
selection  screen. 

STEP  7  -  The  next  screen  involves  the  existing  in’.ut  form  for 
the  ADD  option  of  the  menu.  The  following  page  is  a  reproduction, 
as  all  of  these  screens  in  this  section  are,  of  the  next  PPROG 
screen.  In  this  screen  you  select  modify  because  you  need  to  add 
the  new  field  you  entered  in  the  table. 
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PPRCX5  MenuAction  Menu 


STEP  8  -  This  last  menu  screen  lets  you  modify  the  existing  form 
based  on  the  modification  requirements.  In  this  case  you  would 
select  Field  from  the  menu  across  the  top  of  the  form  and  insert 
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the  new  field  where  you  desire.  After  this  action  is  complete 
select  DO- IT!  from  the  menu  bar  or  press  the  [F2]  key. 

Field  Area  Border  Page  Style  Multi  Help  DO- IT!  Cancel  Form 
Place,  erase,  reformat,  recalculate,  or  wrap  a  field 
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

1 .  SQUADRON  MONTH  YEAR 

2.  MANNING  AVERAGE  TOTAL  GAINS  LOSSES  CATI/CATII/CATIII 

PILOTS  /  / 

NFOS  /  / 

AIRCREW 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

Modify  Form  View 

After  completing  the  screen  modification  you  then  repeat  the 
same  procedure  for  the  EDIT  menu  and  the  VIEW/MANNING  information. 
They  are  the  same  steps  just  different  forms.  When  all  of  the 
forms  have  been  modified  select  DO- IT!  form  the  current  menu  or 
press  the  [F2]  key.  PPROG  will  save  the  changes  you  made  and 
regenerate  the  scripts  using  the  modified  table  and  screens.  For 
any  additional  help  with  PPROG  consult  the  Paradox  users  manual. 

B .  Data  Archiving 

The  difference  between  an  archive  and  backup  copy  is  the  archive 
is  a  historical  record  of  all  of  the  data  entered  into,  and 
possibly  deleted  from,  the  database.  A  backup  copy  is  an  exact 
reproduction  of  the  records  contained  in  the  database  at  the 
present  time.  Archiving  is  an  essential  procedure  of  database 
operations.  It  is  useful  for  providing  several  iterations  of 
historical  records  that  have  been  deleted  from  the  existing 
database  and  to  provide  a  secondary  backup  copy  of  current 
application  records. 

Data  archiving  is  accomplished  in  a  similar  manner  as  data 
backup,  presented  in  section  one  of  this  manual.  Archiving  should 
be  done  simultaneously,  during  data  backup,  to  prevent  deleting  any 
data  without  a  floppy  disk  copy  and  to  provide  more  available  space 
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on  the  hard  disk.  Given  the  lack  of  available  hard  disk  space  on 
the  current  Z-284  system's,  archiving  is  a  necessity  in  the 
department.  It  is  recommended  only  two  years  of  current  Training, 
Readiness  and  Flight  Hour 

data  be  kept  on  the  system.  This  will  provide  enough  data  to 
encompass  an  entire  training/deployment  cycle  for  a  squadron  (18 
months)  and  leave  six  months  for  contingency  purposes.  This  two 
years  of  data  will  require  approximately  650Kb  of  memory  to  store. 
If  current  hard  disk  limitations  remain  in  effect,  this  will  still 
leave  about  300Kb  for  other  documents  and  files.  It  is  strongly 
recommended  that  the  remaining  applications  in  use  be  purged  of 
their  outdated  data  to  free  up  more  memory. 

Data  archiving  makes  use  of  the  Paradox  copy  command,  however 
there  are  some  differences  between  archiving  and  making  backup 
copies.  To  begin,  archiving  is  a  dynamic  record  of  all  data  ever 
stored  in  the  ZTRAX  database.  Backup  copies  are  just  a  copy  of  the 
current  records  in  use  on  ZTRAX.  The  difference  in  the  copy 
commands  is  subtle,  but  important.  To  make  archive  copies  you 
should  first  make  backup  copies  as  described  in  section  one.  Next, 
using  the  same  copy  command,  copy  INDIVIDUAL  records  for  the  newest 
files  in  the  database  (they  should  be  ones  you  just  entered  into 
ZTRAX)  onto  the  archive  disk.  If  you  copy  the  entire  table  you 
will  delete  the  existing  table  on  the  archive  disk.  This  will 
destroy  all  historical  data  on  the  disk  and  replace  it  with  another 
table.  Every  month  you  should  archive,  then  delete,  18  records 
from  the  database.  That  is  one  Training  and  Readiness  Report  and 
one  Flight  Hour  Report  for  each  squadron. 
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To  archive  records  follow  these  procedures: 

1.  Select  Tools  from  the  main  menu. 


View  Ask  Report  Create  Modify  Image  Forms  TOOLS  Scripts  Rename, 
PARADOX  Main  Menu 


2.  Select  More  from  the  Tools  menu. 


Rename  QuerrySpeed  Export  In5)ort  Copy  Delete  More 
^Add^Se^c^^Bcnotv^Protec^^Chanq^tfork^i^Directo^ 

TOOLS  Menu 


3.  Select  Add  from  the  Tools/More  menu. 


Add  MultiAdd  FormAdd  Subtract  Empty  Protect  ToDos 
^Ad^record^ir^on^tabl^t^thos^i^anothe^^^^^^^^^ 

Add  Menu 


4.  At  the  Table  prompt  select  the  table  to  copy,  in  this  example 
we  will  use  the  FLTHRS  table. 


Table:  FLTHRS 
PARADOX  Tools /Table  Menu 

5.  After  you  enter  the  table  name  and  press  return  Paradox  will 
request  a  new  name  to  copy  the  table  to.  Because  this  is  an 
archive  copy  we  use  the  ssune  name  for  the  table  but  specify  a  new 
drive  and  directory.  In  this  case,  we  use  the  A  drive,  ZTRAX 
subdirectory  and  the  FLTHRS  table  name. 
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Table:  A:\ZTRAX\FLTHRS 
PARADOX  Tools/Table  Menu 

6.  Next,  Paradox  will  display  the  following  screen.  Select 
Update  with  the  cursor  and  press  the  return  key.  Paradox  will 
automatically  update  the  records  in  the  destination  file.  It  is 
essential  archiving  be  done  AFTER  new  data  entries  for  the  month 
are  completed.  This  will  ensure  the  archive  copy  is  correct  and 
complete . 


NewEntries  Update 
Add  Menu 

Archiving  is  another  essential  procedure  which  will  insure 
the  integrity  of  ZTRAX.  It  makes  use  of  another  simple  Paradox 
utility,  Tool s /Add/Update . 
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C.  PLIMPORT 

FLIMPORT  is  a  Paradox  utility  designed  to  allow  direct  data 
transfer  from  floppy  disks  into  Paradox  database  tadiles.  Either 
individual  files  or  an  entire  disk  can  be  updated  by  using  a  batch 
processing  option  within  FLIMPORT.  The  activation  of  this  utility 
will  eliminate  all  the  manual  data  entry  currently  required  to 
update  the  ZTRAX  database.  Also,  the  time  required  for  edits  of 
data  entry  errors  will  be  reduced  to  a  nominal  amount. 

To  effectively  use  this  utility  the  files  on  the  floppy  disk 
must  be  in  a  fixed- length  ASCII  format.  This  capability  is  avail¬ 
able  from  some  Navy  communications  centers  however,  it  is  not 
currently  a  standardized  practice.  Once  the  floppy  disks  contain¬ 
ing  the  monthly  reports  are  received  from  the  communications 
center,  they  can  be  readily  transferred  to  the  ZTRAX  database 
tables  through  a  specification  file.  To  use  this  specification 
file  you  must  first  identify  all  of  the  fields  contained  in  the 
monthly  messages.  These  are  the  fields  names  used  in  the  ZTRAX 
tables.  You  then  assign  a  field  length  for  each  field.  These  are 
also  identified  in  the  ZTRAX  tables  as  either  A  for  ASCII 
character,  N  for  numeric  or  D  for  date.  Once  these  have  been 
identified  in  the  specification  file  the  data  transfer  can  begin. 
The  FLIMPORT  process  is  an  extremely  useful  tools  which  saves  hours 
of  data  entry  and  edit  time.  Paradox  provides  documentation  in  the 
users  manual  and  a  FLIMPORT. README  file  in  the  main  program.  Both 
of  these  sources  aid  in  the  construction  of  a  specification  file 
and  the  implementation  requirements  necessary  to  run  FLIMPORT  in 
the  desired  batch  processing  mode. 
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VII.  MENU  HIERARCHY 

The  following  diagrams  of  the  menu  hierarchy  will  help  new  users 
to  the  ZTRAX  application  navigate  their  way  around  the  program's 
menu  structure.  An  important  note  about  any  menu  in  ZTRAX  or 
Paradox,  use  the  escape  key  anytime  to  back  up  one  menu  level.  If 
you  are  lost  continue  to  back  up  the  menu  chain  until  you  find  a 
menu  you  are  familiar  with. 


READINESS  FLTHRS  Leave 


ADD 


EDIT 


VIEW 


r  ^  ^  ^  ^  ^  1 

MANNING  R-LFVELS  FLTACT  EXHRS  CONT  PERSTEMPO 


READINESS  Menu  Structure 
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